Vous connaissez probablement cette situation : votre employeur ou client stocke ses sources sous Git, et vous impose d’utiliser votre adresse mail professionnelle pour commiter dans les repos de l’entreprise ; mais vous intervenez aussi sur des projets open-source, et vous souhaitez utiliser une autre adresse mail… et vous en avez assez de saisir git config user.email "moi@mon-hebergeur-perso.com" à chaque nouveau repo sur lequel vous travaillez !
Git 2.13, qui n’est plus tout jeune, répond à ce besoin de façon assez élégante !
En 2017, à la sortie de Git 2.13, une nouvelle instruction dans le fichier de configuration a changé les choses : on peut désormais inclure d’autres fichiers de configuration, et surtout définir des inclusions conditionnelles ! J’avais vu passer la nouveauté, mais à l’époque, je n’avais pas compris tout de suite l’utilité…
Petit rappel : dans Git, pour pouvoir commiter, il faut définir qui nous sommes, afin que chaque commit ait un auteur identifiable. Cet auteur doit avoir un nom et une adresse email, afin de pouvoir être contacté en cas de besoin. N’oublions pas qu’à l’origine, Git a été développé pour gérer les sources du noyau Linux, sur lesquelles de nombreux intervenants contribuent. Pour définir ces informations, la commande git config est notre amie.
Et les configurations de Git peuvent être faites à différents niveaux : au niveau de l’installation (system), au niveau de l’utilisateur connecté (global) ou au niveau du repository (local). Donc, normalement, vous avez une fois tapé les commandes suivantes :
git config --global user.name "Christophe Marchand"
git config --global user.email cmarchand@www.oxiane.comCeci est parfait pour tous les repository de mon employeur. Mais quand je travaille sur le code d’un client, je dois travailler avec une autre adresse mail, par exemple christophe.marchand@client.com. Et du coup, pour chaque repo de ce client, je dois redéfinir la valeur de mon adresse mail, car il prend par défaut celle qui est configurée de façon globale.
Heureusement, comme moi, vous êtes des gens ordonnés ! Vous rangez vos repo dans une arborescence organisée, par client, par projet, etc… et Git vous permet maintenant de surcharger votre configuration globale par répertoire !
Reprenons notre exemple : mon fichier ~/.gitconfig contient ceci :
[user]
name = Christophe Marchand
email = cmarchand@www.oxiane.comeMais depuis la version 2.13, je peux faire des inclusions conditionnelles. Et c’est ce que je fais !
[user]
name = Christophe Marchand
email = cmarchand@www.oxiane.com
[includeIf "gitdir:~/devel/client1/"]
path = ~/devel/client1/gitconfig.inc
[includeIf "gitdir:~/devel/client2/"]
path = ~/devel/client2/gitconfig.inc
[includeIf "gitdir:~/devel/github/"]
path = ~/devel/github/gitconfig.incEt je peux maintenant définir mes différents fichiers de configuration, par client, ou pour mon hébergeur de projets open-source :
~/devel/client1/gitconfig.inc[user]email = christophe.marchand@client1.com
~/devel/client2/gitconfig.inc[user]email = c.marchand-ext@client2.eu
~/devel/github/gitconfig.inc[user]email = christophe@marchand.top
La syntaxe complète des includes est disponible dans la documentation Git. Et ce mécanisme est généralisable. Par exemple, si vous utilisez systématiquement une authentification en Https, mais avec des paramètres différents par serveur, et bien il suffit que vous veniez spécifier ces réglages d’authentification dans le fichier de configuration de chaque cible. Par exemple, j’ai défini une section http spécifique à un client, sans spécifier d’URL, alors que j’aurais eu plusieurs sections différentes avec des URL dedans, ce qui donnait avant des choses illisibles :
Avant
[http "https://gitlab.client1.com"]
# secret ![http "https://git.client2.eu"]# encore secret !
Ensuite :
~/devel/client1/gitconfig.inc[http]# secret !
~/devel/client2/gitconfig.inc[http]# secret !
Voilà voilà ! Pas une grande nouveauté, mais quelque chose de vraiment pratique !