Comment les développeurs core de Git configurent-ils et utilisent-ils Git ?

• Scott Chacon, auteur de « Pro Git », explique quelques réglages Git qu’il a activés globalement et pourquoi
• Une grande partie de ces réglages lui viennent en réalité de développeurs qui travaillent sur le code source core de Git
• Voici une configuration ~/.gitconfig qui rend Git meilleur

  [column]  
  ui = auto  
  [branch]  
  sort = -committerdate  
  [tag]  
  sort = version:refname  
  [init]  
  defaultBranch = main  
  [diff]  
  algorithm = histogram  
  colorMoved = plain  
  mnemonicPrefix = true  
  renames = true  
  [push]  
  default = simple  
  autoSetupRemote = true  
  followTags = true  
  [fetch]  
  prune = true  
  pruneTags = true  
  all = true  
  
  # Pourquoi s’en priver ?  
  
  [help]  
  autocorrect = prompt  
  [commit]  
  verbose = true  
  [rerere]  
  enabled = true  
  autoupdate = true  
  [core]  
  excludesfile = ~/.gitignore  
  [rebase]  
  autoSquash = true  
  autoStash = true  
  updateRefs = true  
  
  # Réglages selon les préférences personnelles (décommentez si nécessaire)  
  
  [core]  
  # fsmonitor = true  
  # untrackedCache = true  
  [merge]  
  # (utiliser « diff3 » si votre version de Git est antérieure à 2.3)  
  # conflictstyle = zdiff3  
  [pull]  
  # rebase = true  
  

Comment les développeurs core de Git configurent-ils Git ?

• Sur la mailing list Git, Felipe Contreras a déjà proposé à l’équipe core de supprimer tous leurs réglages et alias pour essayer Git tel quel, avec sa configuration par défaut
• À l’issue de cette expérience, 9 réglages et 3 alias ont été proposés comme nouvelles valeurs par défaut

  merge.conflictstyle = zdiff3  
  rebase.autosquash = true  
  rebase.autostash = true   
  commit.verbose = true  
  diff.colorMoved = true  
  diff.algorithm = histogram  
  grep.patternType = perl  
  feature.experimental = true  
  branch.sort = committerdate  
  

• Ces réglages n’ont pas encore été adoptés comme valeurs par défaut
• Mais il est intéressant de constater que beaucoup de développeurs Git ont du mal à utiliser Git sans en activer au moins certains
• Plus intéressant encore : la plupart d’entre vous ne savent probablement pas du tout ce que cela signifie
• L’article les explique en trois catégories
  • Ce qui rend clairement Git meilleur (Clearly Makes Git Better)
  • Pourquoi s’en priver ? (Why the Hell Not?)
  • Une question de goût (A Matter of Taste)

# Ce qui rend clairement Git meilleur

Trier la liste des branches

• Par défaut, Git trie les branches par ordre alphabétique, mais il peut être plus utile de les trier par date du dernier commit
• Les réglages suivants permettent de trier les branches par commits récents et de les afficher en colonnes

  git config --global column.ui auto  
  git config --global branch.sort -committerdate  
  

Trier la liste des tags

• Pour trier les tags par version plutôt que par ordre alphabétique, utilisez ce réglage

  git config --global tag.sort version:refname  
  

Définir le nom de la branche par défaut

• Pour définir le nom de la branche par défaut lors de l’initialisation d’un nouveau dépôt, utilisez ceci

  git config --global init.defaultBranch main  
  

Améliorer les réglages de diff

• Remplace l’algorithme de diff par défaut par histogram pour obtenir des comparaisons plus précises
• Pour détecter les déplacements de code et les afficher en couleur, ajoutez ces réglages

  git config --global diff.algorithm histogram  
  git config --global diff.colorMoved plain  
  git config --global diff.mnemonicPrefix true  
  git config --global diff.renames true  
  

Améliorer les réglages de push

• Les réglages suivants permettent d’améliorer le comportement de push

  git config --global push.default simple  
  git config --global push.autoSetupRemote true  
  git config --global push.followTags true  
  

Améliorer les réglages de fetch

• Pour supprimer automatiquement les branches et tags inutiles lors d’un fetch, utilisez ces réglages

  git config --global fetch.prune true  
  git config --global fetch.pruneTags true  
  git config --global fetch.all true  
  

# Pourquoi s’en priver ?

Invite de correction automatique

• Pour détecter les fautes de frappe dans les commandes et proposer une correction, utilisez ceci

  git config --global help.autocorrect prompt  
  

Afficher le diff au moment du commit

• Pour afficher aussi les modifications pendant la rédaction du message de commit, ajoutez ce réglage

  git config --global commit.verbose true  
  

Réutiliser la résolution des conflits

• Pour réutiliser automatiquement des résolutions de conflits précédentes, utilisez les réglages suivants

  git config --global rerere.enabled true  
  git config --global rerere.autoupdate true  
  

Définir un fichier .gitignore global

• Pour définir globalement des fichiers à ignorer, configurez ceci

  git config --global core.excludesfile ~/.gitignore  
  

Améliorer les réglages de rebase

• Pour effectuer automatiquement un squash et un stash lors d’un rebase, utilisez ces réglages

  git config --global rebase.autoSquash true  
  git config --global rebase.autoStash true  
  git config --global rebase.updateRefs true  
  

# Une question de goût

Améliorer l’affichage des conflits de merge

• Pour afficher aussi la version de base lors d’un conflit de fusion, ce réglage peut être utile

  git config --global merge.conflictstyle zdiff3  
  

Utiliser rebase avec pull

• Pour lancer automatiquement un rebase lors d’un git pull, configurez ceci

  git config --global pull.rebase true  
  

Accélérer la détection des modifications de fichiers

• Pour améliorer les performances de commandes comme git status, vous pouvez utiliser ces réglages

  git config --global core.fsmonitor true  
  git config --global core.untrackedCache true  
  

# Conclusion

• Grâce à ces réglages, Git peut devenir plus agréable à utiliser, et certains sont activement utilisés même par les développeurs core
• En optimisant la configuration de Git, il est possible d’améliorer son flux de travail et de l’utiliser plus efficacement

[brainypooh]

« Le plus intéressant, c’est que la plupart d’entre vous n’ont absolument aucune idée de ce que cela signifie. » Ça pique juste là où il faut. Tremblement.

[tested]

Ce n’est pas --global, mais -global ?

[xguru]

--global est correct. Il y a eu une erreur lors du copier-coller. Cela a été corrigé.

[kyc1682]

Options de configuration Git populaires

[ilikeall]

La réutilisation de la résolution des conflits, c’est vraiment bien.

[tujuc]

Pour les diff, j’utilise git-delta afin de les afficher dans un format TUI.

  10   │ [core]  
  11   │     pager = delta  
  12   │ [interactive]  
  13   │     diffFilter = delta --color-only  
  14   │ [delta]  
  15   │     line-numbers = true  
  16   │     side-by-side = true  
  17   │     navigate = true  
  18   │     diff-so-fancy = true  
  19   │     hyperlinks = true  

Sinon, si on veut éviter de se compliquer la vie, tig... hahaha
Il y aurait quelque chose de mieux... ?

[GN⁺]

Commentaires Hacker News

• Mon alias préféré est git out. Il liste tous les commits qui n’ont pas été poussés. Je l’utilise tout le temps

  [alias]   
    out = "log @{u}.."   
  

• Pendant que beaucoup de gens réfléchissent à leur ~/.gitconfig, je recommande vivement delta comme compagnon du CLI de git
• Mon ~/.gitconfig ressemble à ceci

  [alias]  
    co = checkout  
    ci = commit  
    st = status  
    br = branch  
    hist = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short  
    type = cat-file -t  
    dump = cat-file -p  
    dft = difftool  
  [tag]  
    sort = version:refname  
  [tar "tar.xz"]  
    command = xz -c  
  [tar "tar.zst"]  
    command = zstd -T0 -c  
  [log]  
    date = iso-local  
  [pull]  
    ff = only  
  [diff]  
    tool = difftastic  
  [safe]  
    directory = *  
  [advice]  
    detachedHead = false  
  [init]  
    defaultBranch = master  
  

• Je me demande pourquoi la signature des commits ne figure pas dans cette config. C’est facile à faire avec des clés SSH modernes

  [user]  
    name = xyz  
    email = [e-mail]  
    signingkey = ~/.ssh/id_algorithm.pub  
  
  [commit]  
    gpgsign = true  
  [tag]  
    gpgsign = true  
  
  [gpg]  
    format = ssh  
  
  # restrict allowed signers  
  # echo "$(git config --get user.email) namespaces=\"git\" $(cat ~/.ssh/id_*.pub)" >> ~/.git_allowed_signers  
  [gpg "ssh"]  
    allowedSignersFile = ~/git_allowed_signers  
  

  • Sur GitHub, on peut ajouter une clé SSH à la fois pour l’authentification et pour la signature. Il faut l’ajouter deux fois, mais une fois configuré, cela permet de retirer le label « unverified » des commits
• Options de configuration Git populaires de Julia Evans
• Quelques options supplémentaires que j’aime bien

  [apply]  
    # Remove trailing whitespaces  
    whitespace = fix  
  [color "diff"]  
    whitespace = red reverse  
  [diff]  
    colorMovedWS = allow-indentation-change  
  [format]  
    pretty = fuller  
  [log]  
    date = iso  
  [pull]  
    ff = only  
  

• Ma configuration est ici. En gros, tout y était déjà réglé (sauf l’UI en colonnes). C’est probablement parce que j’ai lu de bons articles de Scott et d’autres
• Je suis d’accord avec la recommandation d’utiliser (z)diff3. L’article sous-estime son importance. Un diff en trois directions permet de résoudre des conflits qui ne peuvent pas l’être avec le style par défaut
  • Avec le style par défaut, ajouter du contenu en conflit au même endroit ne se distingue pas d’une suppression au même endroit. Pour faire la différence, il faut pouvoir voir la base
  • J’en parle plus en détail ici : diff3 should be the default
  • Comment résoudre mécaniquement les conflits de rebase (ou de merge) en utilisant le style diff3
• J’ai découvert qu’on peut configurer git pour utiliser le pager qu’on préfère. Du coup, je l’ai réglé sur bat
  • git config --global core.pager bat
  • https://github.com/sharkdp/bat/ bat - un cat avec coloration syntaxique