Ce qui contrôle réellement l’e-mail d’un commit
L’e-mail de l’auteur d’un commit est défini par la configuration Git de la machine qui crée le commit, et non par l’e-mail affiché sur votre profil GitHub. L’e-mail de votre profil GitHub est un réglage distinct, utilisé pour les notifications, la récupération de compte et certaines actions via l’interface web. Si vous commitez depuis un terminal, l’adresse inscrite dans l’objet commit provient de votre valeur locale user.email. Toute la subtilité est là : modifier l’e-mail de votre profil n’a aucun effet sur les futurs commits en ligne de commande, et modifier votre configuration Git locale n’a aucun effet sur les commits déjà poussés.
La configuration Git contrôle l’e-mail attaché aux futurs commits effectués en ligne de commande. Source
Avant de changer quoi que ce soit, comprenez ce que vous auditez. Vous ne cherchez pas à effacer votre e-mail de GitHub. Vous cherchez à décider quelle adresse doit apparaître sur les commits que vous créez désormais, et si certains de vos dépôts dépendent encore de l’ancienne adresse pour l’attribution ou les outils.
Étape 1 : inspectez l’identité que portent actuellement vos commits
Commencez par regarder ce que contiennent réellement vos commits récents. Dans un dépôt qui vous appartient, lancez un log qui affiche les champs e-mail de l’auteur et du committer pour les derniers commits. L’objectif est de voir la chaîne d’adresse exacte, pas encore de juger si elle est sensible. Faites-le dans chaque dépôt où vous poussez depuis la ligne de commande, car la configuration locale peut différer d’un dépôt à l’autre.
Ensuite, vérifiez la configuration effective que Git utilisera dans ce dépôt. Git résout la configuration à partir de plusieurs portées, et une valeur au niveau du dépôt prime sur une valeur globale. Si vous voyez une adresse que vous ne reconnaissez pas, elle peut provenir d’un réglage local au dépôt, d’un fichier de configuration inclus, ou d’une variable d’environnement de votre shell. Notez ce que vous trouvez avant de modifier ; un audit que vous ne pouvez pas reproduire n’est pas un audit.
Étape 2 : séparez les deux réglages dans votre esprit
Utilisez ce tableau de décision pour garder distincts le réglage du profil et celui du commit. Il décrit des mécanismes généraux que vous pouvez vérifier dans votre propre compte et votre terminal ; il n’affirme pas de libellés de menu ni de chemins d’interface actuels.
| Question | Régi par | Ce que le changement affecte | Ce qu’il n’affecte pas |
|---|---|---|---|
| Quel e-mail apparaît sur mon profil GitHub ? | Paramètres d’e-mail du compte GitHub | Affichage du profil, notifications, récupération de compte | L’e-mail de l’auteur des commits que vous créez localement |
| Quel e-mail est inscrit dans un nouveau commit ? | Configuration Git locale user.email | Les futurs commits effectués depuis cette machine ou ce dépôt | Les commits déjà créés ou poussés |
| Les anciens commits changeront-ils si je passe en noreply ? | Rien d’automatique | Rien | Les objets commit existants conservent leur e-mail d’auteur d’origine |
| Puis-je masquer mon e-mail dans les futurs commits publics ? | Configuration Git locale plus une adresse noreply | Les nouveaux commits que vous créez après le changement | L’historique passé, les forks et les copies en cache ailleurs |
À retenir du tableau : vous avez deux leviers indépendants. Actionnez le levier du commit si votre préoccupation concerne les futurs push. N’attendez pas du levier du profil qu’il fasse ce travail.
Étape 3 : choisissez une adresse noreply et configurez-la localement
GitHub propose une option d’adresse noreply. Le format exact est documenté par GitHub et peut évoluer, donc copiez l’adresse depuis les paramètres de votre propre compte plutôt que depuis un article de blog. Une fois que vous l’avez, définissez-la comme e-mail de commit dans la portée qui correspond à votre flux de travail.
Une séquence sûre :
- Copiez l’adresse noreply fournie par GitHub depuis les paramètres de votre compte.
- Décidez la portée : définissez-la globalement si tous les dépôts de la machine doivent l’utiliser, ou par dépôt si vous contribuez à des projets qui attendent une identité différente.
- Appliquez le réglage avec
git configà la portée choisie. - Créez un commit de test dans une branche de travail et inspectez son e-mail d’auteur avant de pousser.
- Ne poussez qu’après que le commit de test affiche l’adresse noreply.
GitHub propose une option d’adresse noreply ; modifier l’adresse configurée ne réécrit pas les commits existants. Source
C’est ce second point que les gens oublient. Passer en noreply est un contrôle tourné vers l’avenir. Cela ne réécrit pas les commits existants et ne supprime pas votre ancienne adresse des objets commit déjà publics. Si un dépôt a été forké ou mis en miroir, ces copies conservent les données de commit d’origine quoi que vous configuriez aujourd’hui.
Étape 4 : vérifiez séparément le comportement de l’interface web et des outils
Les commits créés via l’interface web de GitHub, ou par des bots et des intégrations, peuvent emprunter un chemin d’identité différent de celui de votre terminal local. Ne supposez pas qu’un changement de configuration locale couvre tous les commits qui arrivent dans un dépôt. Examinez les champs d’auteur des commits provenant de différentes sources, et notez ceux que vous contrôlez directement. Pour les intégrations que vous ne contrôlez pas, la réponse honnête est que vous ne pouvez pas définir leur identité de commit depuis votre ordinateur portable ; vous pouvez seulement décider de continuer ou non à utiliser cette intégration.
Étape 5 : décidez quoi faire de l’ancien historique
Vous avez trois options réalistes, et aucune n’est « faire disparaître l’exposition ancienne ».
| Option | Ce qu’elle fait | Coût et limites |
|---|---|---|
| Laisser l’historique tel quel | Aucun risque de casser des clones ou des références | Les anciens commits gardent l’e-mail d’auteur d’origine |
| Réécrire l’historique dans votre propre dépôt | Modifie les objets commit à partir de maintenant dans ce dépôt | La réécriture est perturbante, n’atteint pas les forks ni les miroirs, et sort du cadre pour la plupart des utilisateurs |
| Supprimer ou faire tourner l’adresse exposée | Réduit l’exposition future si l’adresse est encore active | Ne modifie pas les commits qui la contiennent déjà |
Pour la plupart des lecteurs, le bon choix est le premier ou le troisième : cessez d’ajouter l’adresse aux nouveaux commits, et traitez les anciens commits comme définitivement publics. Si l’adresse exposée est celle que vous utilisez encore pour la connexion ou la récupération, demandez-vous si elle doit rester associée au compte. C’est une décision de sécurité du compte, pas de configuration Git.
Erreurs courantes
- Changer l’e-mail du profil et croire que les commits sont corrigés. Le réglage du profil et l’identité de commit sont distincts. Les futurs commits en terminal porteront encore l’ancienne adresse tant que vous n’aurez pas modifié la configuration Git locale.
- Définir noreply globalement sans vérifier les surcharges de dépôt. Un
user.emaillocal au dépôt l’emportera sur votre valeur globale. Auditez chaque dépôt où vous poussez. - Pousser un commit de test sur une branche publique. Vérifiez l’e-mail d’auteur sur une branche de travail ou avec un log local avant de pousser.
- Croire qu’un passage en noreply efface l’historique. Cela ne réécrit pas les commits existants et n’atteint ni les forks, ni les miroirs, ni les copies en cache.
- Supposer que toute source de commit est sous votre contrôle. Les commits via l’interface web et les commits d’intégration peuvent utiliser des identités différentes ; vérifiez-les plutôt que de supposer.
- Prendre un profil modifié pour une suppression. Changer ce que votre profil affiche ne supprime pas les données stockées et ne modifie pas les objets commit.
Protéger votre propre empreinte
L’e-mail de commit n’est qu’un canal étroit. Votre empreinte publique comprend aussi les pseudonymes et les profils liés à cette adresse sur d’autres plateformes. Si vous auditez une adresse parce qu’elle est apparue quelque part de public, l’étape utile suivante consiste à voir quels comptes publics y sont associés. Le guide de TruthsSeek sur comment trouver les comptes liés à une adresse e-mail détaille ce processus de vérification, et la page de recherche GitHub à /find/github/ est un point de départ pour vérifier un pseudonyme connu. TraceSeek, l’application couverte par TruthsSeek, vérifie un nom d’utilisateur sur 3 000+ plateformes et offre un premier scan gratuit ; le produit indique qu’un scan prend 20–30 secondes. Ces outils font apparaître des correspondances publiques comme des pistes, pas comme une preuve de propriété, et ils ne modifient pas les paramètres des plateformes ni n’exposent de dossiers privés. Utilisez-les pour cartographier ce qui est déjà public, puis effectuez les changements de configuration sur les plateformes elles-mêmes.
Une routine réaliste : corrigez votre identité Git locale une fois, vérifiez-la avec un commit de test, puis revérifiez périodiquement les champs d’auteur des commits provenant de nouveaux outils ou machines. Traitez chaque commit poussé comme une donnée publique permanente, car en pratique c’est généralement le cas.
Faits clés
- La configuration Git contrôle l’e-mail attaché aux futurs commits effectués en ligne de commande.
- GitHub propose une option d’adresse noreply ; modifier l’adresse configurée ne réécrit pas les commits existants.
- Le réglage de l’e-mail du profil GitHub et le réglage local de l’e-mail de commit Git sont deux contrôles distincts aux effets différents.
- TraceSeek vérifie les noms d’utilisateur sur 3 000+ plateformes et offre un premier scan gratuit, avec un temps de scan indiqué par le produit de 20–30 secondes.
- Les correspondances publiques de noms d’utilisateur sont des pistes, pas une preuve de propriété de compte.