Maîtrise de la configuration utilisateur Git : nom, e-mail et éditeur par défaut

La configuration utilisateur Git semble ennuyeuse jusqu'à ce que vos premiers commits apparaissent avec la mauvaise adresse e-mail, que le graphique de contribution de votre entreprise manque la moitié de vos modifications, ou que Git ouvre un éditeur que vous ne savez pas quitter. La solution est généralement simple : définissez délibérément votre nom, votre e-mail et votre éditeur, puis sachez comment les remplacer pour un dépôt spécifique.

L'important n'est pas de mémoriser chaque indicateur git config. Il s'agit de comprendre où Git lit la configuration et comment vérifier la valeur finale que Git utilisera avant de faire un commit.

Comprendre les niveaux de configuration Git

Git utilise une hiérarchie de fichiers de configuration. Les paramètres définis à un niveau supérieur peuvent être remplacés par des paramètres définis à un niveau inférieur. Comprendre ces niveaux vous permet d'appliquer les paramètres de manière granulaire ou universelle.

Il existe trois niveaux de configuration principaux :

Niveau système (--system) : S'applique à chaque utilisateur et à chaque dépôt sur l'ensemble de la machine. Ceci est rarement utilisé pour l'identité utilisateur, sauf si vous gérez un serveur de construction dédié.
Niveau global (--global) : S'applique à tous les dépôts appartenant à l'utilisateur actuel sur la machine. C'est là que vous définissez généralement votre user.name et user.email principaux.
Niveau local (--local) : S'applique uniquement au dépôt spécifique dans lequel vous vous trouvez actuellement. Cela vous permet d'utiliser une identité différente pour un projet spécifique (par exemple, travail vs personnel).

Afficher les paramètres de configuration actuels

Avant d'apporter des modifications, il est utile de voir ce que Git est actuellement configuré pour utiliser. Vous pouvez lister les paramètres pour tous les niveaux ou seulement pour un niveau spécifique :

# Afficher tous les paramètres de tous les niveaux
git config --list

# Afficher uniquement les paramètres globaux
git config --global --list

Configurer votre identité utilisateur (nom et e-mail)

Votre nom et votre adresse e-mail sont les informations utilisateur les plus critiques stockées dans Git. Ils identifient qui a effectué la modification.

1. Définir l'identité utilisateur globale

Pour la plupart des utilisateurs, définir le nom et l'e-mail globalement est la première étape recommandée. Cela garantit que tous vos futurs projets porteront cette identité par défaut. Remplacez les espaces réservés par vos informations réelles.

Définir le nom :

git config --global user.name "Votre Nom Complet"

Définir l'e-mail :

Il est fortement recommandé d'utiliser l'adresse e-mail associée à votre compte GitHub/GitLab/Bitbucket, surtout si vous utilisez des clés SSH ou la signature de commits.

git config --global user.email "[email protected]"

Meilleure pratique : Utilisez l'adresse e-mail exacte liée à votre fournisseur d'hébergement pour garantir que les contributions s'affichent correctement sur les plateformes distantes.

2. Remplacer l'identité pour un dépôt spécifique (niveau local)

Parfois, vous pouvez contribuer à un projet qui nécessite une attribution spécifique (par exemple, utiliser un e-mail professionnel pour un dépôt client). Vous pouvez remplacer les paramètres globaux uniquement dans ce dépôt.

Accédez au répertoire racine du dépôt et exécutez les commandes de configuration sans l'indicateur --global :

# Accédez au répertoire de votre projet
cd ~/projets/projet-client-alpha

# Définir un nom spécifique pour ce dépôt
git config user.name "Nom Professionnel"

# Définir un e-mail spécifique pour ce dépôt
git config user.email "[email protected]"

Lorsque vous commitez dans ce dépôt, Git utilisera ces paramètres locaux au lieu des paramètres globaux.

Comment Git choisit l'identité

Lorsque Git traite un commit, il vérifie les niveaux dans l'ordre : Local -> Global -> Système. Le premier paramètre qu'il trouve pour user.name ou user.email est celui utilisé.

Configurer votre éditeur de texte par défaut

Lorsque Git a besoin d'une entrée de votre part, comme pour écrire un message de commit, une instruction de rebase ou une note de résolution de conflit de fusion, il ouvre votre éditeur de texte configuré. Par défaut, il peut s'agir d'un éditeur de terminal de base comme vi ou vim, ce qui peut être difficile pour les nouveaux utilisateurs.

Définir la préférence d'éditeur global

Vous pouvez configurer Git pour utiliser votre éditeur préféré sur toutes vos machines ou projets à l'aide de l'indicateur --global.

Utiliser VS Code comme éditeur

Si vous préférez Visual Studio Code et que l'intégration en ligne de commande (code) est installée, définissez-le comme suit :

git config --global core.editor "code --wait"

L'indicateur --wait est crucial ; il indique à Git de suspendre l'exécution jusqu'à ce que vous fermiez le fichier ouvert dans VS Code, garantissant ainsi que le message de commit est finalisé.

Utiliser Sublime Text comme éditeur

Pour les utilisateurs de Sublime Text :

git config --global core.editor "subl -n -w"

Utiliser Nano ou Vim (si déjà familier)

Si vous préférez un éditeur de terminal simple :

# Pour Nano
git config --global core.editor "nano"

# Pour Vim (souvent par défaut)
git config --global core.editor "vim"

Tester votre configuration d'éditeur

La façon la plus simple de tester si votre configuration d'éditeur fonctionne est d'initier un amendement qui nécessite un message, ou de créer un commit sans fournir l'indicateur -m :

# Créer un fichier factice et tenter un commit sans -m
touch tempfile.txt
git add tempfile.txt
git commit 
# Cela devrait ouvrir votre éditeur nouvellement configuré.

Corriger une identité incorrecte existante

Modifier user.name et user.email affecte les commits futurs. Cela ne réécrit pas les commits qui existent déjà. Si votre dernier commit a le mauvais auteur et que vous ne l'avez pas encore poussé, vous pouvez le modifier après avoir corrigé la configuration :

git config user.name "Nom Correct"
git config user.email "[email protected]"
git commit --amend --reset-author

Si le mauvais commit est déjà poussé vers une branche partagée, soyez prudent. Réécrire l'historique publié peut perturber les autres. Pour une branche privée, un amendement et un push forcé peuvent être acceptables :

git push --force-with-lease

Pour une branche partagée, la réponse la plus sûre est souvent de laisser l'historique tranquille et de corriger l'identité pour les commits futurs. Si de nombreux commits doivent être réparés, utilisez un outil de réécriture d'historique uniquement après coordination avec l'équipe.

Vérifier d'où vient une valeur

Lorsque Git se comporte étrangement, git config --list peut être trop bruyant. Utilisez --show-origin pour que Git vous indique quel fichier a fourni chaque valeur :

git config --show-origin --list

Vous pourriez voir une sortie comme :

file:/Users/alex/.gitconfig    [email protected]
file:.git/config               [email protected]

Cela signifie que la valeur locale du dépôt l'emporte dans le dépôt actuel. C'est le moyen le plus rapide de diagnostiquer "J'ai changé mon e-mail global mais Git utilise toujours l'ancien".

Vous pouvez également demander une seule valeur :

git config --show-origin user.email

Une configuration travail et personnel qui tient la route

Un modèle courant consiste à conserver une identité personnelle globale et à remplacer les dépôts professionnels localement :

git config --global user.name "Alex Rivera"
git config --global user.email "[email protected]"

cd ~/travail/api-paiements
git config user.email "[email protected]"

Certaines équipes préfèrent des clones séparés dans des répertoires séparés. Les versions plus récentes de Git prennent en charge les inclusions conditionnelles, qui peuvent charger automatiquement une configuration de travail pour les dépôts sous un chemin :

# ~/.gitconfig
[user]
    name = Alex Rivera
    email = [email protected]

[includeIf "gitdir:~/travail/"]
    path = ~/.gitconfig-travail

# ~/.gitconfig-travail
[user]
    email = [email protected]

Les règles de correspondance de chemin exact peuvent être un peu surprenantes selon les plateformes, alors testez-les dans un dépôt réel :

cd ~/travail/un-depot
git config --show-origin user.email

Problèmes d'éditeur que vous pouvez éviter

Le paramètre core.editor est surtout important lorsque Git a besoin d'un message ou d'un fichier d'instructions : commits de fusion, rebases interactifs, amendements de commit et commits sans -m. Si Git ouvre Vim et que vous n'êtes pas à l'aise, cela peut donner l'impression que la commande est bloquée.

Pour VS Code, l'indicateur --wait n'est pas optionnel :

git config --global core.editor "code --wait"

Sans --wait, Git peut ouvrir le fichier et continuer immédiatement avant que vous ayez fini d'écrire le message. Pour les serveurs en terminal uniquement, nano est souvent moins surprenant :

git config --global core.editor "nano"

Vous pouvez tester l'éditeur sans créer de modification de projet réelle :

git commit --allow-empty

Écrivez un message de test, enregistrez, puis supprimez le commit vide si vous ne le souhaitez pas :

git reset --soft HEAD~1

Signature de commit et comptes d'hébergement

Votre e-mail Git est distinct de l'authentification. Les clés SSH, les jetons d'accès personnels et la connexion au navigateur déterminent si vous pouvez pousser. user.email détermine l'e-mail de l'auteur qui est écrit dans l'objet commit.

Les fournisseurs d'hébergement associent généralement les commits à votre compte par adresse e-mail. Si vous utilisez un e-mail de confidentialité, définissez cette adresse exacte :

git config --global user.email "[email protected]"

Si votre organisation exige des commits signés, l'identité n'est qu'une partie de la configuration. Vous aurez peut-être aussi besoin de user.signingkey, commit.gpgsign, ou d'une configuration de signature SSH. Gardez cela séparé de la configuration de base nom/e-mail afin de pouvoir déboguer une couche à la fois.

Auteur, commiteur et remplacements d'environnement

Git stocke à la fois un auteur et un commiteur sur chaque commit. La plupart du temps, il s'agit de la même personne. Ils diffèrent lorsque quelqu'un applique un correctif d'un autre développeur, rebase des commits ou modifie un commit écrit à l'origine par quelqu'un d'autre.

Vous pouvez voir les deux champs avec :

git log --format=fuller -1

Cette sortie est utile lorsque quelqu'un dit "Git a utilisé le mauvais e-mail" mais que le journal normal d'une ligne ne montre que l'auteur. Le commiteur peut être différent car un mainteneur a appliqué le correctif, ou parce qu'un rebase a recréé le commit.

Git peut également lire l'identité à partir de variables d'environnement :

GIT_AUTHOR_NAME="Robot de construction" \
GIT_AUTHOR_EMAIL="[email protected]" \
git commit -m "Mettre à jour les fichiers générés"

Les systèmes CI utilisent parfois ce modèle. C'est bien quand c'est intentionnel, mais déroutant quand un pipeline fait fuiter ces variables dans un shell de développeur ou un script local. Si Git ignore votre configuration, vérifiez l'environnement :

env | rg '^GIT_(AUTHOR|COMMITTER)'

Désactivez les remplacements accidentels avant de commiter :

unset GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL

Une petite politique d'équipe qui empêche un historique désordonné

Pour les équipes, la meilleure politique de configuration utilisateur Git est généralement courte :

Utilisez votre vrai nom ou le même identifiant que votre équipe reconnaît.
Utilisez un e-mail d'entreprise pour les dépôts d'entreprise.
Utilisez un e-mail vérifié du fournisseur d'hébergement pour que les commits soient attachés au bon compte.
Ne réécrivez pas l'historique partagé simplement pour nettoyer les anciennes métadonnées d'auteur, sauf si l'équipe est d'accord.
Documentez le core.editor préféré uniquement si vos scripts d'intégration en dépendent.

Vous pouvez ajouter une vérification pré-commit ou pré-push pour les domaines d'e-mail, mais restez amical. Un hook local qui bloque chaque commit parce que quelqu'un travaille en binôme depuis une machine différente créera des frictions. Une politique côté serveur ou une vérification CI sur les branches protégées est généralement plus facile à gérer.

Voici une vérification locale simple que vous pouvez exécuter manuellement avant de pousser du code de travail :

git config user.email
git log --format='%h %ae %s' origin/main..HEAD

Si un commit montre un e-mail personnel sur une branche d'entreprise, corrigez-le avant d'ouvrir la demande de tirage. C'est beaucoup plus facile que de réparer une branche fusionnée plus tard.

Dépannage des surprises de configuration courantes

Si git config --global user.email affiche la bonne valeur mais que les commits utilisent toujours autre chose, vérifiez si vous êtes dans un dépôt avec un remplacement local :

git config --local user.email
git config --show-origin user.email

Si la valeur locale est incorrecte, remplacez-la ou désactivez-la :

git config user.email "[email protected]"
git config --unset user.email

Désactiver la valeur locale fait que Git revient à la valeur globale. C'est souvent plus propre que de définir la même valeur dans chaque dépôt.

Si Git dit Author identity unknown, cela signifie que Git n'a pas pu trouver de user.name et user.email utilisables dans la configuration ou l'environnement. Définissez les deux, pas seulement un :

git config --global user.name "Alex Rivera"
git config --global user.email "[email protected]"

Sur les serveurs partagés, évitez --system sauf si vous gérez la machine pour tout le monde. Une identité au niveau système peut faire que des utilisateurs non liés commitent accidentellement en tant que même personne. Les agents de construction sont la principale exception, et même là, il est généralement préférable de configurer explicitement l'espace de travail CI ou le compte de service.

Liste de contrôle rapide

Utilisez git config --global pour les paramètres qui s'appliquent partout, comme votre identité et votre éditeur par défaut.
Utilisez git config (sans indicateurs) dans un dépôt pour remplacer les paramètres globaux localement.
Utilisez git config --show-origin --list lorsque vous devez savoir quel fichier l'emporte.
Utilisez git commit --amend --reset-author uniquement lorsque la réécriture du commit le plus récent est appropriée.
Utilisez --wait lors de la configuration d'éditeurs graphiques pour que Git attende que vous ayez fini d'éditer.