Les réglages par défaut de Git vous font perdre du temps

Voici la config git que je fais tourner sur chaque machine, onze réglages globaux et vingt alias, chacun présent parce qu'il élimine une contrariété quotidienne précise. Volez tout.

Il y a quelque temps, un collègue m'a regardé pousser une toute nouvelle branche et m'a arrêté :

« Attends, comment ça a marché ? Pas de --set-upstream ? »

Une ligne de config. Il tapait la solution de contournement depuis des années.

Cette conversation est la raison d'être de cet article. La plupart des développeurs font tourner git avec les réglages d'usine, et les réglages d'usine de git ne sont pas conçus pour vous. Ils sont conçus pour la compatibilité. Git préfère vous interrompre mille fois plutôt que de vous surprendre une seule fois.

Alors tout le monde paie tranquillement la même taxe quotidienne, la plupart du temps sans même s'en rendre compte :

• fatal: The current branch has no upstream branch, on a tapé le correctif si souvent que c'est devenu un réflexe
• Des commits de merge qui polluent l'historique parce qu'un simple pull merge
• .DS_Store qui apparaît dans chaque git status sur chaque projet Mac
• Résoudre le même conflit de rebase pour la cinquième fois
• Commiter sur le dépôt du bureau avec un email personnel

Chacun de ces cas est un correctif d'une ligne que git fournit, mais désactivé.

Ce qui suit est ma vraie config, celle qui me suit sur chaque machine. Pas un déversement de tout ce que git supporte : chaque ligne ici a mérité sa place en éliminant une contrariété réelle. Deux actes : d'abord les réglages globaux, parce qu'ils changent le comportement de git partout ; puis les alias, parce qu'ils changent votre vitesse de conduite.

🪪 Acte un : l'identité, le réglage qui peut vous mettre dans l'embarras

Commençons par celui qui a des conséquences :

git config --global user.name "Paurush Rai"
git config --global user.email "personal@email.com"

Évident. Mais voici la partie que la plupart des développeurs ne mettent jamais en place : le routage automatique travail/personnel.

Je garde le code de mon employeur sous ~/Developer/company/. Un bloc dans ~/.gitconfig :

[includeIf "gitdir:~/Developer/company/"]
    path = ~/.gitconfig-work

Et ~/.gitconfig-work contient exactement une chose :

[user]
    email = work@company.com

Désormais l'identité est décidée par l'emplacement du dépôt. Clonez quoi que ce soit dans company/ → email de travail, automatiquement. Tout le reste → email personnel. Pas besoin de s'en souvenir, pas de configuration par dépôt, pas d'email personnel dans le journal d'audit de l'entreprise, et pas d'email professionnel sur les side projects du week-end.

(Remarquez ce qui n'est pas dans le fichier de travail : le nom. includeIf se superpose à la config globale, donc le fichier de travail ne déclare que ce qui diffère, l'email. Tout le reste est hérité.)

Ça compte plus qu'il n'y paraît, parce que les emails de commit sont permanents. Poussez avec la mauvaise identité et c'est dans l'historique pour toujours ; GitHub attribue le commit à quel que soit le compte propriétaire de cet email. L'identité devrait être une propriété du dépôt, pas de ce que vous avez pensé à taper la dernière fois.

⚙️ Acte un, suite : les réglages de comportement

Onze lignes. Chacune élimine une contrariété récurrente précise.

Ne plus jamais voir « no upstream branch »

git config --global push.autoSetupRemote true

L'erreur que chaque développeur a mémorisée, fatal: The current branch has no upstream branch, existe pour que git puisse demander la permission de faire l'évidence. Ce réglage l'accorde une fois pour toutes. Le premier push sur une nouvelle branche fonctionne, tout simplement. (C'est la ligne qui a arrêté mon collègue en pleine phrase.)

Arrêter de générer des commits de merge accidentels

git config --global pull.rebase true

Un git pull par défaut, c'est fetch + merge, ce qui explique comment des commits « Merge branch 'main' of github.com... » finissent par tapisser votre historique. Avec ce réglage, pull rejoue vos commits locaux par-dessus ce qui est arrivé. Historique linéaire, pas de bruit.

Faire démarrer les nouveaux dépôts sur main

git config --global init.defaultBranch main

Sinon chaque git init démarre sur master et vous la renommez plus tard. Une ligne, plus jamais à y penser.

Arrêter d'accumuler des branches mortes

git config --global fetch.prune true

Quand une branche est supprimée sur le remote (PR mergées, la plupart du temps), votre copie locale de origin/cette-branche traîne pour toujours. Ceci supprime automatiquement les références obsolètes à chaque fetch. Votre liste de branches reste honnête.

Bannir .DS_Store de chaque dépôt pour toujours

git config --global core.excludesfile ~/.gitignore_global
echo ".DS_Store" > ~/.gitignore_global

Un fichier d'ignore global s'applique par-dessus le .gitignore propre à chaque dépôt. Les déchets de macOS, les fichiers swap d'éditeur, traités une fois, à l'échelle de la machine, au lieu d'une fois par projet.

La trinité de résolution de conflits

git config --global merge.conflictstyle zdiff3
git config --global rerere.enabled true
git config --global rebase.autostash true

Trois réglages qui transforment ensemble la résolution de conflits :

zdiff3 ajoute une troisième section aux marqueurs de conflit, le texte original dont les deux côtés sont partis. Les marqueurs standards vous montrent « le vôtre » et « le leur » et vous font deviner l'intention. Voir l'ancêtre commun transforme deviner en lire.

rerere (« reuse recorded resolution ») est le succès surprise des onze. Git enregistre comment vous résolvez chaque conflit, et quand le même conflit réapparaît (les rebases adorent répéter les conflits), il rejoue votre résolution automatiquement. Le cinquième conflit identique se résout tout seul.

autostash supprime la danse « cannot rebase: you have unstaged changes ». Git range vos modifications, fait le rebase, et les restaure. Ce que vous étiez en train de faire survit.

Confort de vie, deux lignes

git config --global diff.algorithm histogram
git config --global branch.sort -committerdate

Histogram produit des diffs nettement plus propres que l'algorithme Myers par défaut, moins de ces blocs mélangés où git associe des lignes sans rapport. Et trier les branches par activité récente veut dire que git branch montre ce sur quoi vous travaillez réellement en premier, pas une archéologie alphabétique.

⌨️ Acte deux : les alias

Les réglages changent le comportement de git. Les alias changent votre vitesse. J'en garde vingt, soigneusement choisis, groupés selon ce qu'ils font gagner.

Les pilotes quotidiens

st     = status -sb
cm     = commit -m
sw     = switch
co     = checkout
amend  = commit --amend --no-edit

status -sb mérite une note : c'est le statut en deux lignes. L'état de la branche plus les fichiers modifiés, sans paragraphes de conseils que vous avez arrêté de lire il y a des années.

Voir clairement

lg     = log --oneline --graph --decorate -20
last   = log -1 HEAD --stat
d      = diff
ds     = diff --staged
whoami = !echo "$(git config user.name) <$(git config user.email)>"

git lg est mon « où en suis-je », vingt commits, dessinés en graphe. Et git whoami boucle la boucle sur l'Acte un : lancez-le dans n'importe quel dépôt et il affiche exactement quelle identité signera le prochain commit. Dans company/ il montre mon email de travail ; partout ailleurs, le personnel. La confiance, vérifiée en une commande.

Annuler sans crainte

unstage = restore --staged
undo    = reset --soft HEAD~1
wip     = !git add -A && git commit -m "wip: checkpoint"

undo décommite sans rien détruire, les changements retournent dans le staging. wip capture un instantané de tout avant une opération risquée. La plupart de l'anxiété liée à git vient de ne pas connaître le chemin sûr du retour ; ce sont ces alias, le chemin sûr du retour.

Les coups de pro

pf      = push --force-with-lease
fixup   = commit --fixup
ri      = rebase -i --autosquash
cleanup = !git branch --merged | grep -vE "^\*|main|master" | xargs git branch -d

pf est le plus important : --force-with-lease force le push seulement si le remote est où vous l'avez vu pour la dernière fois, ce qui veut dire qu'il refuse physiquement d'écraser le travail d'un collègue arrivé entre-temps. Il n'y a aucune situation où le --force brut est le meilleur choix. L'aliaser signifie que mes doigts ne tapent jamais la version dangereuse.

Le duo fixup + ri est le workflow d'historique propre : commitez un correctif ciblé sur un commit antérieur, puis un rebase interactif replie tout automatiquement à sa place.

🎯 La partie qui rend tout ça permanent

Voici la chose avec la config : la construire est facile. La garder, c'est le vrai problème. Une config qui ne vit que sur votre machine actuelle est une config que vous reconstruirez de mémoire sur la suivante.

Mon ~/.gitconfig n'est pas un fichier isolé, c'est un symlink vers un dépôt de dotfiles qui commit et pousse automatiquement chaque changement dès qu'il se produit. Quand j'ai ajouté un nouvel alias récemment, un agent en arrière-plan l'avait déjà commité sur GitHub avant même que j'aie fini de le tester.

(Ce système, symlinks plus un agent launchd, pas de cron, pas d'outils tiers, est sa propre histoire, que j'ai racontée séparément.)

Conséquence : toute cette configuration, routage d'identité et les vingt alias inclus, atterrit sur n'importe quelle machine avec un seul install.sh. Configurez une fois, gardez pour toujours.

📋 Le tout, prêt à copier-coller

# identité (modifiez ces lignes !)
git config --global user.name "Your Name"
git config --global user.email "you@personal.com"
 
# comportement
git config --global init.defaultBranch main
git config --global push.autoSetupRemote true
git config --global pull.rebase true
git config --global fetch.prune true
git config --global core.excludesfile ~/.gitignore_global
echo ".DS_Store" > ~/.gitignore_global
git config --global merge.conflictstyle zdiff3
git config --global rerere.enabled true
git config --global rebase.autostash true
git config --global diff.algorithm histogram
git config --global branch.sort -committerdate
 
# alias
git config --global alias.st "status -sb"
git config --global alias.cm "commit -m"
git config --global alias.sw "switch"
git config --global alias.co "checkout"
git config --global alias.amend "commit --amend --no-edit"
git config --global alias.lg "log --oneline --graph --decorate -20"
git config --global alias.last "log -1 HEAD --stat"
git config --global alias.d "diff"
git config --global alias.ds "diff --staged"
git config --global alias.unstage "restore --staged"
git config --global alias.undo "reset --soft HEAD~1"
git config --global alias.wip '!git add -A && git commit -m "wip: checkpoint"'
git config --global alias.pf "push --force-with-lease"
git config --global alias.fixup "commit --fixup"
git config --global alias.ri "rebase -i --autosquash"
git config --global alias.cleanup '!git branch --merged | grep -vE "^\*|main|master" | xargs git branch -d'
git config --global alias.root "rev-parse --show-toplevel"
git config --global alias.aliases "config --get-regexp ^alias"
git config --global alias.whoami '!echo "$(git config user.name) <$(git config user.email)>"'

Plus le routage d'identité, si vous gardez le code de travail dans un répertoire dédié :

git config --global includeIf."gitdir:~/Developer/company/".path ~/.gitconfig-work
printf '[user]\n    email = you@work.com\n' > ~/.gitconfig-work

La leçon

Aucun de ces réglages n'est impressionnant tout seul. C'est bien le but.

Les réglages par défaut de git optimisent pour ne jamais surprendre personne, ce qui veut dire qu'ils interrompent tout le monde. Chaque ligne ci-dessus convertit une interruption récurrente en silence, et le silence s'accumule. Multipliez quelques secondes économisées et un commit avec le mauvais email évité, sur chaque dépôt que vous toucherez jamais, et cette demi-heure de configuration devient parmi les moments les plus rentables que vous passerez sur votre tooling.

Mon collègue a mis en place push.autoSetupRemote le même après-midi où il l'a vu. La solution de contournement qu'il tapait depuis des années a disparu avec une ligne, il lui a juste fallu voir quelqu'un ne pas payer la taxe pour réaliser que c'était optionnel.

Considérez cet article comme ce moment, sous forme écrite. Lancez cat ~/.gitconfig et regardez ce qu'il y a vraiment dedans.

Les réglages par défaut sont pour la compatibilité. La configuration est pour vous.

Qu'y a-t-il dans votre gitconfig ?

Je suis toujours à la recherche du prochain correctif d'une ligne. Si vous avez un réglage ou un alias qui a mérité sa place, c'est comme ça que j'ai trouvé la moitié des miens.