.gitignore, .gitattributes, .editorconfig : à quoi sert chaque fichier caché d'un projet

Un même dépôt de code contient souvent ces trois fichiers cachés à sa racine, sans que leur répartition des rôles saute aux yeux d’un développeur qui découvre le projet : chacun agit à un niveau différent, et aucun ne peut remplacer les deux autres.

Le .gitignore est le plus connu des trois : il liste des motifs de fichiers que Git doit ignorer, pour ne jamais les suivre ni proposer de les ajouter : dépendances téléchargées, fichiers générés par la compilation, secrets locaux. Son effet s’arrête net à la frontière du suivi : un fichier déjà ajouté à l’historique avant sa règle d’exclusion continue d’apparaître dans les changements, une confusion fréquente chez qui découvre l’outil.

Le .gitattributes agit sur des fichiers qui, eux, restent activement suivis : il normalise les fins de ligne entre Windows et Unix (* text=auto), déclare certains fichiers comme binaires pour éviter une fusion textuelle incohérente, ou redirige des motifs de fichiers volumineux vers Git LFS. Sans cette déclaration explicite, Git LFS n’intercepterait aucun fichier correspondant à ses motifs, quelle que soit sa taille.

Le .editorconfig sort du périmètre de Git : il configure directement l’éditeur de texte (taille d’indentation, espaces ou tabulations, encodage, ligne vide finale), pas le comportement du gestionnaire de version. Les règles se combinent par dossier, celles du fichier le plus proche du fichier édité prenant le pas sur celles d’un fichier plus général, sauf directive root = true, qui arrête la recherche vers les dossiers parents.

Les trois fichiers coexistent donc sans se chevaucher : le .gitignore décide ce qui entre dans l’historique, le .gitattributes décide comment Git traite ce qui y est déjà, et le .editorconfig décide comment l’éditeur affiche et sauvegarde le code source avant même que Git n’intervienne. Un projet bien configuré combine généralement les trois plutôt que d’en choisir un seul.