5 fichiers de configuration Git que tout développeur devrait connaître

La plupart des développeurs connaissent .gitignore, mais l’écosystème de configuration de Git va bien plus loin. Dispersés dans votre répertoire personnel et à la racine de vos projets, une poignée de fichiers de configuration Git essentiels façonnent discrètement le comportement de votre dépôt, l’expérience de vos collaborateurs avec votre code, et la cohérence de Git entre différentes machines. Les comprendre vous évite des bugs subtils, des historiques désordonnés et des frictions dans la collaboration.

Voici cinq fichiers de configuration Git qu’il vaut la peine de bien connaître.

1. .gitconfig — Votre identité Git personnelle et vos préférences de comportement

Emplacement : ~/.gitconfig (global) ou .git/config (niveau dépôt)

.gitconfig est le fichier de configuration Git principal pour votre compte utilisateur. Il stocke votre nom, votre email, votre éditeur par défaut, vos alias et vos préférences comportementales. La configuration Git peut exister à plusieurs niveaux : système, global, local (dépôt), et optionnellement worktree, les configurations plus spécifiques remplaçant les plus générales.

Un modèle pratique emprunté aux configurations dotfiles du monde réel : conservez un ~/.gitconfig pour les paramètres partagés et utilisez les directives includeIf pour charger des surcharges spécifiques à la machine ou au travail sans polluer votre configuration principale.

[includeIf "gitdir:~/work/"]
  path = ~/.gitconfig_work

Cela garde vos dotfiles portables tout en accommodant les différences entre machines — quelque chose qu’une simple approche par lien symbolique ne peut pas gérer proprement. Vous pouvez en apprendre davantage sur la configuration conditionnelle dans la documentation officielle de configuration Git.

2. .gitignore — Garder les fichiers non suivis hors de votre index

Emplacement : racine du projet, sous-répertoires, ou ~/.config/git/ignore (global)

.gitignore n’affecte que les fichiers non suivis. Il ne supprimera pas les fichiers déjà commités dans le dépôt. C’est une source courante de confusion — si vous devez arrêter de suivre un fichier commité, vous devez d’abord exécuter git rm --cached <fichier> avant que la règle d’exclusion ne prenne effet.

Pour les fichiers que vous voulez ignorer globalement — fichiers d’échange de l’éditeur, .DS_Store, miniatures du système d’exploitation — configurez un fichier d’exclusion global via core.excludesFile dans votre .gitconfig :

[core]
  excludesFile = ~/.config/git/ignore

Cela garde les fichiers .gitignore du projet propres et focalisés sur les exclusions spécifiques au projet, plutôt qu’encombrés par les préférences d’éditeur personnelles de chaque développeur. La documentation officielle gitignore de Git explique en détail les règles de correspondance et la précédence.

3. .gitattributes — Bien plus que les fins de ligne

Emplacement : racine du projet (commité dans le dépôt)

.gitattributes est l’un des fichiers de configuration Git les plus sous-utilisés. Oui, il gère la normalisation des fins de ligne (text=auto), mais il contrôle également :

• Le comportement de fusion — configure comment certains types de fichiers sont fusionnés
• La gestion des fichiers binaires — indique à Git de ne pas différencier ou fusionner certains types de fichiers
• Le comportement d’export — utilisez export-ignore pour exclure des fichiers des sorties git archive (utile pour les artefacts CI)
• Les pilotes de diff — attribue une sortie diff lisible par l’humain à des formats comme .docx ou du JS minifié

Pour les projets frontend, marquer les fichiers de verrouillage ou les ressources regroupées avec les attributs appropriés prévient les conflits de fusion inutiles et le bruit dans les diffs. La gamme complète des attributs et comportements est décrite dans la documentation officielle gitattributes.

4. .git-blame-ignore-revs — Nettoyer blame après les commits de formatage

Emplacement : racine du projet (commité dans le dépôt)

Lorsque vous exécutez un formateur comme Prettier ou ESLint sur l’ensemble d’une base de code, git blame devient presque inutile — chaque ligne pointe vers le commit de formatage plutôt que vers l’auteur original.

.git-blame-ignore-revs résout ce problème. Listez les SHA de commit complets que vous voulez que blame ignore :

# Passage de formatage Prettier
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

Ensuite, configurez Git pour l’utiliser :

git config blame.ignoreRevsFile .git-blame-ignore-revs

GitHub reconnaît ce fichier automatiquement. C’est un petit ajout avec un impact significatif sur la revue de code et la lisibilité de l’historique. Le comportement est documenté dans la documentation officielle git blame.

5. .mailmap — Normaliser les identités des contributeurs

Emplacement : racine du projet (commité dans le dépôt)

Les contributeurs changent d’adresse email, utilisent des noms différents sur différentes machines, ou font des commits avant de configurer Git correctement. .mailmap vous permet de canonicaliser ces identités dans l’historique de votre projet.

Jane Smith <jane@company.com> <jane@oldmail.com>

Les commandes comme git shortlog et git log refléteront l’identité corrigée sans modifier l’historique de commit sous-jacent. Cette fonctionnalité est particulièrement utile pour les projets open source et les dépôts de longue durée où les identités des contributeurs évoluent avec le temps. Le format et le comportement sont décrits dans la documentation officielle mailmap.

Conclusion

Ces cinq fichiers de configuration Git — .gitconfig, .gitignore, .gitattributes, .git-blame-ignore-revs, et .mailmap — résolvent chacun un problème distinct dans les flux de travail de développement réels. Ils ne concernent pas seulement les préférences personnelles. Plusieurs d’entre eux doivent être commités directement dans votre dépôt, où ils améliorent l’expérience de chaque contributeur de l’équipe. Commencez par ceux qui répondent à vos points de friction les plus immédiats, et votre flux de travail Git en sera nettement plus propre.

FAQ

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.