Git, configuration et fourberies
Tags: git, wtf
Published: 2019-10-29 07:54:28

---
title: Git, configuration et fourberies
published: true
description: Comment configurer Git pour son usage personnel et pour troller ses collègues 
cover_image: https://thepracticaldev.s3.amazonaws.com/i/9ajlkl8jv168bup7cdl8.png
canonical_url: https://maximeblanc.fr/blog/git-configuration-et-fourberies
tags: git, wtf
---

Souvenez-vous, les lignes de commandes suivantes sont celles que vous avez exécutées après avoir installé Git.

```bash
git config --global user.name jean-smaug
git config --global user.email maximeblanc.dev@gmail.fr
```

Elles ont permis à Git de vous connaitre en tant qu'utilisateur. Preuve en est, si vous faites un `git log --pretty=full`, votre nom d'utilisateur et votre email sont associés à tous les commits que vous avez créés.

Vous êtes-vous déjà demandé pourquoi il y avait un `--global` dans cette commande ?
Aujourd'hui on répond à cette question et on voit comment gagner du temps dans l'utilisation de Git.

## Les fichiers de configuration

Il existe trois fichiers de configuration :

- **système** : relatif à la machine, nous ne l'utiliserons pas
- **global** : relatif à un utilisateur du système
- **local** : relatif au dépôt

Avec cette information vous aurez compris que si on configurait l'utilisateur sans l'option `--global` on devrait le configurer pour chacun de nos dépôts Git. Dans une logique de non-perte de temps, ce n'est pas la meilleure solution.

Les chemins des fichiers de configuration sont les suivants :

- `~/.gitconfig` pour le global
- `dossier-projet/.git/config` pour le local

Commençons par inspecter le fichier de configuration globale. Soit vous l'ouvrez à l'emplacement précédemment mentionné soit vous pouvez lancer la commande `git config --global --edit`. Il est écrit en [TOML](https://github.com/toml-lang/toml) et ressemble à cela :

```bash
[user]
  email = maximeblanc.dev@gmail.com
  name = jean-smaug
```

Cet exemple contient la section **user** que l'on a configuré via la ligne de commande. Il est bien entendu possible de configurer Git en éditant de fichier manuellement.

## Hiérarchie de configuration

Imaginons que la configuration globale utilisée est celle de mon ordinateur personnel et que je doive travailler sur un projet d'entreprise. Je ne vais pas committer sous l'appellation "jean-smaug", vous vous en doutez.
Depuis le répertoire du projet il me suffit de lancer

```bash
git config user.name maxime blanc
git config user.email maxime@blanc.fr
```

De cette façon, les commits de ce projet appartiendront à **maxime blanc** alors que les commits des autres projets appartiendront à **jean-smaug**.

Même si `user.name` et `user.email` sont définis dans les deux configurations, une seule est prise en compte. La configuration locale est prioritaire sur la configuration globale, elle-même prioritaire sur la configuration système.

Si vous voulez voir la configuration que Git utilise au sein de votre projet la commande `git config --list --show-origin` fera votre bonheur. Cette commande indique les options qui viennent de la configuration locale et celles qui viennent de la configuration globale.

## Quelques options à modifier (ou pas)

Dans cette partie on va passer en revue quelques options qu'il peut être intéressant de modifier. Il en existe [beaucoup d'autres](https://git-scm.com/docs/git-config), ici je présente celle qui pourraient intéresser la majorité d'entre vous.

### Core

```bash
git config core.editor vim
```

L'éditeur utilisé pendant les rebases interactifs, les commits... Vim ou Nano sont de bons choix car léger mais VSCode peut aussi convenir.

```bash
git config core.ignoreCase true
```

Par défaut Git fait la différence entre `index.js` et `INDEX.js`. Les systèmes de fichier FAT et NTFS n'étant pas sensible à la casse, ce paramètre peut être utile pour éviter les problèmes.

### Reseau

```bash
git config fetch.prune true
```

Supprime les copies des références distantes (branches, tags...), qui n'existent plus sur le dépôt distant.

```bash
git config pull.rebase true
```

La commande pull utilisera le rebase plutôt que le merge comme stratégie de mise à jour.

### Rebase

```bash
git config rebase.autoSquash true
```

Permet de squasher les commits de fixup.

```bash
git config rebase.autoStash true
```

Stash les modifications de l'espace de travail avant un rebase et applique le stash à la fin du rebase.

```bash
git config rebase.abbreviateCommands true
```

Utilise les versions courtes des options de rebase, `p` pour `pick`, `r` pour `rename`... lors d'un rebase interactif.

```bash
git config rerere.enabled true
```

Rerere ou **Re**use **re**corded **re**solution, sauvegarde les résolutions de conflits que vous avez traité et les ré-applique automatiquement en cas de conflits identiques.

### Divers

```bash
git config blame.showEmail true
```

Affiche les emails pendant un `git blame`

```bash
git config status.short true
```

Version allégée du `git status`

### Dois-je activer ces options ?

Il n'y a pas de réponse unique, cela dépend de votre façon de travailler.

Il faut savoir que la majorité des customisations proposées est réalisable via la ligne de commande.
Par exemple, executer `git pull --rebase` équivaut à un `git pull` en ayant au préalable activé l'option `pull.rebase` dans la configuration.

Donc si vous ajoutez souvent des options à vos commandes il peut être utile de modifier la configuration.

## Ça reste entre nous 🤫

Dans cette section, je vais présenter quelques techniques pour briser la confiance mutuelle que vous avez avec vos collègues. Et pour cela nous aurons uniquement besoin d'une configuration Git.

### Un monde au mille et une couleurs

On peut modifier le comportement des commandes mais aussi les couleurs des textes dans la console.  
Je vais vous proposer ici 3 configurations à essayer sur votre poste mais surtout sur celui de vos collègues.

#### La version nostalgique des années 80

```toml
[color "status"]
  hint = red
  header = magenta
  added = green
  updated = blue
  changed = yellow
  untracked = cyan
```

Je vous montre le splendide resultat ici, et je vous laisse tester les suivantes par vous même.

![80's](https://thepracticaldev.s3.amazonaws.com/i/mwngfqqgqh4npqwi4riw.jpg)

#### La version pompes funèbres

```toml
[color "status"]
  hint = black
  header = black
  added = black
  updated = black
  changed = black
  untracked = black
```

#### La version ne pas utiliser si vous êtes daltonien 🙃

```toml
[color "status"]
  hint = yellow green
  header = yellow green
  added = yellow green
  updated = yellow green
  changed = yellow green
  untracked = yellow green
```

Ici j'ai présenté la customisation de la commande `git status`, il faut savoir qu'il est aussi possible d'appliquer ces changements sur les blames, les diffs, les branches...
Certes, la configuration de couleur n'est pas la fonctionnalité qui va révolutionner votre façon de travailler, mais le style à son importance comme dirait l'autre.

### Le capitaine Crochet

Si votre équipe a décidé d'utiliser les hooks de pré-commit et/ou de pré-push, vous avez deux solutions :

- La quitter
- Utiliser l'astuce qui suit tout en planifiant votre départ

Pour ignorer les hooks il faut ajouter le paramètre `--no-verify` a sa commande. Mais le taper à chaque fois est pénible.

Pour automatiser le processus il est possible de créer des alias dans le fichier de configuration.

```toml
[alias]
  cm = commit --no-verify
  pu = push --no-verify
```

Ainsi, les commandes `git cm` et `git pu`, "committerons" et "pusherons" en ignorant les hooks.

Bien plus que pour ignorer des hooks, les alias sont très pratiques, ils permettent d'aller plus beaucoup plus vite. Mes alias sont disponibles [ici](https://github.com/jean-smaug/config-files/blob/master/.gitconfig) mais n'hésitez pas à créer les votres !

Le tour est joué, vous pouvez développer tranquillement.

### S'attribuer le travail d'un collègue

Nous avons vu plus haut comment configurer un utilisateur. Lors de cette opération, Git va configurer deux choses :

- l'auteur : celui qui a écrit et commité le code
- le "committeur": celui qui à réalisé les denières manipulations sur les commits

C'est pour cela que sur Github, lorsque vous rebasez le travail d'un autre, vous pouvez voir apparaître deux avatars sur un commit.

![author-and-committer](https://thepracticaldev.s3.amazonaws.com/i/no9ks9d68x0zayiq9fkk.jpg)

Même dans la partie WTF, on peut apprendre des choses 👍

Le but est de modifier l'auteur, car c'est sur l'auteur que Github se base pour les statistiques de contribution.

Vous avez sûrement envie de modifier le fichier de configuration local et d'y apposer votre email, afin d'avoir la priorité sur la configuration globale. Excellent réflexe !
Il existe cependant une façon plus discrète de configurer un utilisateur qui à la priorité sur la configuration locale : les variables d'environnement.

Sur la machine cible, lancez les commandes suivantes laissez le bosser pour vous.

```bash
export GIT_AUTHOR_EMAIL=jack@sparrow.io
export GIT_AUTHOR_NAME=jack sparrow
```

Croyez-moi, ça marche.

![crook](https://thepracticaldev.s3.amazonaws.com/i/8s9eva7271fgyb9catow.png)

## BONUS : le jeu de la Gitime

Une fois la variable d'environnement modifiée, et que votre collègue a poussé son code sur le dépôt, plusieurs solutions :

- Il s'en aperçoit avant de demander une revue, il fait 10 squats pour avoir laissé son poste non verrouillé.
- C'est un autre collègue qui s'en aperçoit pendant la revue, la Gitime prend un gage. Et alors là, il faut être créatif. On peut choisir les classiques chocolatines mais on peut aussi le déguiser, en fée, en Babouche (le singe, pas la chaussure)... Ça lui apprendra à ne pas relire ses PR avant de demander une revue.
- Si jamais la PR est mergée sans qu'il s'en aperçoive alors la, je vous laisse vous arranger entre vous. Mais il ne doit pas s'en sortir indemne.

## Conclusion

Nous avons passé en revue les différentes manières pour adapter Git à sa façon de travailler : configuration, alias, variables d'environnement.

Retenez que l'ordre appliqué pour les options est le suivant :
Configuration système > Configuration globale > Configuration locale > Variable d'environnement > Options de commandes.

Le plus important étant que, vous êtes désormais armés pour lutter contre vos collègues. Puisse le sort vous être favorable.

Si jamais certaines notions ou commandes mentionnées dans l'article ne sont pas claires, restez à l'affût des prochains articles qui aborderont ces points. Je vous invite aussi à consulter la documentation qui est très bien faite.

Merci à Aubin Dugelet pour la relecture.

Merci de m'avoir lu.

## Liens

- [Configuration git partagée](https://stackoverflow.com/questions/18329621/storing-git-config-as-part-of-the-repository)
- [Afficher se configuration globale](https://stackoverflow.com/questions/12254076/how-do-i-show-my-global-git-configuration)
- [Documentation Git](https://git-scm.com/docs/git-config)