Gestion du multi-compte git sur une même machine

le 09/01/2025 par Alexandre Hachim

Tags: Software Engineering, Cloud & Platform, Bonne Pratique, Devops, Craft

Lorsqu’on travaille sur plusieurs projets, il est courant d’avoir différents comptes Git : un pour le travail et un pour les projets personnels, par exemple. Configurer ses comptes sur une même machine peut devenir un casse-tête si ce n’est pas bien organisé. Voici un guide pratique pour gérer le multi-compte Git en toute simplicité.

Pourquoi Gérer Plusieurs Comptes Git ?

En tant que développeur on peut être amené à travailler sur plusieurs projets en parallèle et on peut donc avoir besoin de plusieurs compte git. Par exemple :

Un compte professionnel pour contribuer aux projets d’entreprise.
Un compte personnel pour des projets open source, freelancing, ou expérimentations.

Sans une configuration appropriée, on risque d’utiliser le mauvais compte pour des commits, ce qui peut entraîner des problèmes de droits, de confidentialité ou simplement de confusion.

Pour faciliter le processus, j’ai programmé un petit wizard interactif qui automatise les étapes 1, 2 et 3 ci-dessous. Vous aurez toujours besoin de suivre les étapes 4 et 5 voir la 6 si vous y trouvez votre compte.

Étape 1 : Configurer vos Clés SSH

Dans cet article nous prenons le parti d’utiliser SSH plutôt que HTTPS. Chaque compte doit avoir sa propre paire clé publique/privée. On va donc créer des clés de manière classique. Jusque-là rien de nouveau mis à part qu’on en génère autant que nécessaire.

(En cas de besoin, un article complet est disponible dans la documentation officielle de Github)

1. Générer une clé SSH pour chaque compte :

ssh-keygen -t ed25519 -C "votre-email@pro.com" -f ~/.ssh/id_ed25519_pro
ssh-keygen -t ed25519 -C "votre-email@perso.com" -f ~/.ssh/id_ed25519_perso

2. Ajouter les clés SSH à l’agent :

ssh-add ~/.ssh/id_ed25519_pro
ssh-add ~/.ssh/id_ed25519_perso

3. Associer les clés à vos comptes Git :

On affiche les clés publiques grâce à la commande suivante :

cat ~/.ssh/id_ed25519_pro.pub
cat ~/.ssh/id_ed25519_perso.pub

Puis on les copie-colle dans notre trousseau de clé de notre plateforme git préférée.

(Pour github c’est ici, puis cliquez sur “New SSH key”. Pour plus d’informations, une documentation officielle complète est disponible)

Étape 2 : Configurer le Fichier ~/.ssh/config

Pour simplifier la gestion des différentes clés, nous allons modifier la configuration SSH.

On ouvre le fichier ~/.ssh/config (à créer s’il n’existe pas) puis on ajoute le code suivant :

Host github-pro
	HostName github.com
	User git
	IdentityFile ~/.ssh/id_ed25519_pro

Host github-perso
	HostName github.com
	User git
	IdentityFile ~/.ssh/id_ed25519_perso

(Vous pouvez remplacer github-pro et github-perso par des noms qui vous parlent.)

Étape 3 : Vérifier les hôtes

On peut vérifier que les hôtes précédemment créés sont bien configurés et que les clés SSH sont bien liées :

ssh -T <host>

(Exemple : ssh -T github-perso)

Sur github, une réponse favorable ressemble à ça :

Hi Alex100dre! You've successfully authenticated, but GitHub does not provide shell access.

Étape 4 : Configurer Git pour Chaque Compte

Chaque dépôt peut être configuré pour utiliser un compte spécifique.

1. Configurer globalement les informations utilisateur par défaut :

Pour que votre compte pro soit utilisé par défaut, nous allons définir les configurations utilisateur par défaut de git :

git config --global user.name "Votre pseudo pro"
git config --global user.email "votre-email@pro.com"

2. Configurer un projet pour un compte spécifique :

Lorsque vous travaillez sur un projet personnel, depuis le dossier du projet, entrez les commandes suivantes pour définir les configurations utilisateur spécifiques au dépôt du projet :

git config user.name "Votre pseudo perso"
git config user.email "votre-email@perso.com"

3. Vérifier la configuration :

À tout moment, en cas de besoin, on peut vérifier les configurations utilisateur utilisées depuis le dossier d’un repo avec les commandes suivantes :

git config --get user.name
git config --get user.email

Étape 5 : Manipuler les références distantes d’origine des dépôts

Pour que Git utilise la bonne clé SSH en fonction du dépôt, nous devons ajuster l’URL des remotes.

Sur un dépôt existant déjà en local :

git remote set-url origin git@<host>:<nom-auteur-du-dépôt>/<nom-du-dépôt>.git

Lors du clonage d’un nouveau dépôt :

git clone git@<host>:<nom-auteur-du-dépôt>/<nom-du-dépôt>.git

Le host est la valeur que nous avons définie plus haut dans le fichier ~/.ssh/config.

Par exemple si on veut cloner le dépôt “git@github.com:Alex100dre/multi-ssh-git-wizard.git” avec notre compte perso, on procède comme suit :

git clone git@github-perso:Alex100dre/multi-ssh-git-wizard.git

À tout moment, en cas de besoin, on peut vérifier la référence distante d’origine du dépôt courant avec la commande suivante :

git remote -v

Étape 6 (bonus) : Astuces pour Simplifier le Workflow

Pour simplifier le changement d’information utilisateur git, on peut automatiser les commandes fréquentes en ajoutant des alias dans le fichier ~/.gitconfig :

[alias]
	pro = "!f() { git config user.name 'Alexandre' && git config user.email 'alexandre.hachim@octo.com'; }; f"
	perso = "!f() { git config user.name 'Alexandre' && git config user.email 'alex100dre.pro@gmail.com'; }; f"
	whoisuser = "!f() { git config --get user.name && git config --get user.email; }; f"

On peut ensuite, utiliser ces alias :

git pro
git perso
git whoisuser

Attention cependant, ces alias ne fonctionnent que depuis un dossier de dépôt git. Ce qui est normal étant donné qu’ils permettent de modifier les configurations du dépôt en question.

Conclusion

Avec ces configurations en place, vous pouvez basculer facilement entre vos comptes Git permettant ainsi de travailler sur des projets pour des comptes/clients/usages différents en limitant les fuites de données personnelles, problèmes de droits et autres confusions.

Alternative 1 : Une autre solution consistant à déterminer le compte git à utiliser en fonction de l’emplacement du clone local du repo existe et est documentée ici.

Avantage : Plus besoin de changer les urls distantes de nos repo lors du clonage.
Inconvénient : On doit impérativement ranger nos clones dans les bons dossiers.

Alternative 2 : Une autre solution consistant à déterminer le compte git à utiliser selon le domaine de l’origine existe et fera peut être l’objet d’un prochain article.

Avantage : Plus besoin de changer les urls distantes de nos repo lors du clonage.
Inconvénient : Peut être contraignant si on veut contribuer avec un autre compte que celui configuré pour un domaine particulier.