Git, configuration et fourberies

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
Vous êtes-vous déjà demandé pourquoi il y avait un
--global
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
Les chemins des fichiers de configuration sont les suivants :
- pour le global
~/.gitconfig
- pour le local
dossier-projet/.git/config
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
[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
user.email
Si vous voulez voir la configuration que Git utilise au sein de votre projet la commande
git config --list --show-origin
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
INDEX.js
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
pick
r
rename
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
git pull
pull.rebase
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
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
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
git pu
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.