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

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 et ressemble à cela :

[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

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, ici je présente celle qui pourraient intéresser la majorité d’entre vous.

Core

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.

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.

Réseau

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.

git config pull.rebase true

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

Rebase

git config rebase.autoSquash true

Permet de squasher les commits de fixup.

git config rebase.autoStash true

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

git config rebase.abbreviateCommands true

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

git config rerere.enabled true

Rerere ou Reuse recorded resolution, sauvegarde les résolutions de conflits que vous avez traité et les ré-applique automatiquement en cas de conflits identiques.

Divers

git config blame.showEmail true

Affiche les emails pendant un git blame

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, éxecuter 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

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

Je vous montre le splendide résultat ici, et je vous laisse tester les suivantes par vous-même.

La version pompes funèbres

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

La version ne pas utiliser si vous êtes daltonien 🙃

[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.

[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 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 a réalisé les derniè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.

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.

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

Croyez-moi, ça marche.

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
• Afficher se configuration globale
• Documentation Git