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 :
-
~/.gitconfigpour le global -
dossier-projet/.git/configpour 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.
Reseau
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, 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
[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.
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 à 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.
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.
Top comments (2)
Merci pour ces petites astuces Maxime Blanc ! Toujours aussi instructifs tes posts teintés de cet humour que je ne peux qu'apprécier !
Pour l'améliorer encore (car rien n'est jamais parfait 😉), je suggérerai simplement d'ajouter quelques références par-ci par-là pour les termes plus techniques à des néophytes telles que le rebase, stash, blame et également d'ajouter des screens de la console pour les différentes personnalisation des couleurs afin de donner envie au lecteur de les essayer (quoique les imaginer est aussi un bon exercice 😄)
Déjà, cimer chef ;)
Si par reférence t'entends des liens, t'as raison, je vais le faire.
A la base j'avais mis un message à la fin en mode "si certaines parties sont floues, c'est normal, je les détail dans un prochain article". Mais je peux pas digresser sur ces notions sinon le post ferait 20 min :')
Pour les screens, je vais ajouter la version nostaglique des années 80. Mais c'est mieux si le lecteur les essaye.