Configuration Git : 2e partie

Par Maxime Bréhin • Publié le 27 mars 2023 • 4 min

Savoir configurer Git, c’est super ! Ça permet de préciser des comportements, des aliases, de renseigner nos outils préférés pour travailler avec Git, de personnaliser jusqu’aux couleurs d’affichage des commandes dans le terminal… Mais la configuration, c’est aussi un truc contraignant, parce que le comportement de base n’est pas forcément optimal, parce que ça implique de créer les fichiers de configuration, de répliquer la même configuration sur chaque machine, et parce qu’on n’est pas forcément au courant des choses qu’on peut optimiser !

À la base, ça pourrait être mieux…

C’est un fait plutôt regrettable : Git n’est pas au top d’emblée ! Certains comportements demandent à être optimisés, comme par exemple le pull en mode rebase (rebase = merges pour être exact). Tu ne devrais même pas te poser la question de l’utilité de cette configuration, et pourtant, te voilà à devoir expliciter tout ça.

La raison est simple : les évolutions ne doivent pas changer les comportements nominaux. Dit autrement : tu ne devrais pas voir de différence de comportement suite à une mise à jour de Git. J’admets que cette approche est plutôt discutable, mais sauf en prenant la main sur l’organisation du projet (c’est possible, vu que c’est de l’open-source), ça ne risque pas de changer dans l’immédiat.

Comment alors remédier à ce problème ? Que dirais-tu de lire la doc suivre nos recommandations. Comme on n’est pas trop vaches 🐮, on t’a commenté chaque élément de configuration, histoire que tu aies au moins des pistes pour comprendre à quoi tout ça peut servir.

Côté syntaxe, ça ressemble à un fichier .ini ou à du TOML. En gros on a un bloc dont l’en-tête est définie avec des crochets, suivi de lignes sur le format clé = valeur.

[user]
  name = Max Krieger
  email = max.krieger@git.demo

Tu auras parfois besoin d’agir sur des blocs nommés qui permettent de spécifier certains aspects (parfois appelés drivers) d’une fonctionnalité ou commande. Voici un exemple avec la gestion de la coloration de la commande status :

[color "status"]
  # Print untracked file names in black on yellow background
  untracked = black yellow
  # Print conflicting files in magenta and italics
  unmerged = magenta italic

C’est mignon tout ça, mais je mets ça où ?

On a plusieurs options, mais la plus simple et efficace consiste à renseigner la configuration au global pour ton compte utilisateur·rice. Ça servira ainsi à tous tes projets sur la machine. Tu y trouveras généralement un fichier .gitconfig (et sinon, tu peux le créer). Si tu as un doute, tu peux y accéder depuis ton terminal en faisant un git config --global --edit (attention, ça risque de l’ouvrir par défaut dans vim). Certains éditeurs graphiques permettent aussi d’éditer cette configuration, souvent au sein de leur propre interface.

Si tu es sur Windows, prends garde si les comptes sont stockés sur un serveur : si le réseau tombe, ta configuration Git ne sera alors plus chargée (elle est lue à chaque commande / action Git). Tu ne t’en apercevras pas forcément car Git ne remontera pas d’erreur. Une solution est alors de changer son emplacement en modifiant la variable d’environnement XDG_CONFIG_HOME.

On peut aussi préciser la configuration “locale”, au plus proche du projet. Il s’agit alors du fichier .git/config de ton projet (oui oui, ça n’est pas le même nom 🤦). C’est utile pour préciser ou surcharger certaines infos. Par exemple quand je bosse sur des projets open-source je renseigne mon adresse e-mail perso plutôt que la pro (l’exemple est donné juste après). Et puis on y trouve les définitions des dépôts distants, branches, etc. qui sont évidemment distincts d’un projet à l’autre.

Comment dois-je renseigner ma configuration ?

Au-delà du bon gros copier/coller de notre gabarit de configuration, tu voudras parfois changer certains éléments. Tu peux soit modifier le fichier à la main, soit faire ça via la ligne de commande.

Si tu édites un fichier de configuration à la main et que tu as peur de tout casser, sache que le parser de Git saura te dire à quelle ligne tu as une erreur. Va donc sans crainte.

Pour la méthode “safe”, tu peux appeler la commande selon le gabarit suivant :

git config --global nom-de-bloc.clé valeur
# Exemple pour préciser ton éditeur préféré :
# git config --global core.editor 'code --wait'

Si tu retires l’option --global ça travaillera sur la configuration locale.

git config user.email mon-email@tld.domain

Comment Git charge-t-il ma configuration ?

Les fichiers de configuration sont lus à chaque commande Git. D’abord au niveau global, puis au niveau local / projet. La configuration globale est alors enrichie, voire surchargée par les définitions locales.

Enfin, selon ce que tu cherches à réaliser comme manipulation, tu pourras généralement surcharger certaines options au moment de l’exécution d’une commande, si elle le permet.

# Partant de la configuration qui refuse de base la fusion
# en mode "fast-forward" (`merge.ff` à `false`), on peut
# surchager avec l’option `ff` lors de l’appel à la commande
git merge --ff sub-feature

Si on devait résumer ça plus simplement : la configuration au plus proche de la commande gagne !

Et pour le partage ?

Si tu pratiques déjà Git, tu connais peut-être le fichier .gitignore que tu peux mettre à la racine de ton projet pour le partager. Tu te dis alors peut-être naïvement que tu peux faire pareil avec la configuration et créer un fichier .gitconfig au même emplacement… Sauf que non ! À croire que ça aurait été trop simple.

De base, la configuration n’est pas partagée. Tu peux alors ruser, par exemple en précisant dans ta configuration locale un chemin vers un fichier de configuration tiers.

# ❌ Ne fais pas ça, c’est sans intérêt
git config include.path <path-to-custom-config>

Mais on en revient au même problème : il faut passer par la configuration pour renseigner… le chemin vers la configuration (sauf qu’en plus ici il faut le faire sur chaque machine et pour chaque projet). Ça craint, mais on n’a d’autre choix que de répliquer nos confs.

Bon après ça n’est pas la mer à boire. On le fait une fois pour toutes à l’installation de la machine et puis roule mon pull 🐔 (désolé, ça m’est venu comme ça 😉).