Git ignore tout par défaut et ne suit que les fichiers autorisés

Présentation

Le fichier .gitignore sert à indiquer à Git quels chemins ne doivent pas être indexés. La plupart des projets adoptent l'approche inverse : ils laissent tout visible et ajoutent des règles d'exclusion pour les artefacts temporaires (.DS_Store, node_modules, etc.). L’article propose de renverser ce paradigme en ignorant tout dès le départ et en ne débloquant que les fichiers réellement nécessaires au dépôt.

Un exemple minimal pour un projet Go montre la syntaxe suivante :

*
!.gitignore
!*.go
!README.md
!go.mod
!go.sum

Le caractère générique * capture chaque fichier et répertoire. Les lignes précédées de ! annulent l’exclusion pour les chemins listés, ce qui crée une liste blanche explicite.

Fonctionnement technique

Git parcourt le .gitignore ligne par ligne, la première règle qui correspond à un chemin détermine son statut. Ainsi, la règle globale * marque chaque entrée comme ignorée, puis les règles !*.go, !go.mod, etc., rétablissent le suivi pour les fichiers correspondants. Cette logique repose sur le principe de « last match wins », ce qui rend l’ordre des lignes crucial.

Pour que les répertoires contenant les fichiers whitelistés soient également visibles, il faut souvent ajouter une règle !*/ ou déclarer explicitement chaque sous‑dossier. Sans cela, Git ne descend jamais dans un répertoire déjà ignoré, même si un fichier interne est whitelisté.

La commande git check-ignore -v chemin/fichier permet de vérifier la règle appliquée à un fichier donné. L’option -v affiche le fichier .gitignore et la ligne exacte qui a conduit à l’exclusion, ce qui facilite le diagnostic lorsqu’un fichier attendu n’apparaît pas dans le staging.

Implications pratiques

Cette stratégie élimine les commits accidentels de fichiers de configuration locale, de caches ou de dépendances binaires. Elle impose cependant une discipline stricte : chaque nouveau type de fichier doit être ajouté à la liste blanche, sous peine de disparaître du suivi. Dans les projets complexes, la taille du .gitignore peut rapidement dépasser les quelques lignes présentées, comme le fichier de 207 lignes observé dans le projet typescript-go.

Le principal avantage réside dans la prévisibilité : le dépôt ne contiendra que les artefacts explicitement déclarés, ce qui réduit la surface d’erreur lors de la révision de code. En revanche, la maintenance du fichier devient plus lourde, surtout lorsqu’une équipe ajoute fréquemment de nouveaux outils de build ou des scripts auxiliaires.

Un autre point de vigilance concerne les outils d’intégration continue. Certains systèmes génèrent automatiquement des fichiers temporaires (par ex. coverage.out) qui, s’ils ne sont pas whitelistés, seront ignorés et ne pourront pas être archivés dans les artefacts de build.

Limites et bonnes pratiques

La méthode n’est pas universelle. Dans les dépôts où la majorité des fichiers sont source et où les artefacts indésirables sont rares, la surcharge de déclarations explicites peut ralentir la compréhension du .gitignore. De plus, la règle * ne différencie pas les répertoires des fichiers ; sans !*/, tout le contenu d’un répertoire reste invisible, même si des sous‑fichiers sont explicitement whitelistés.

Il est recommandé de placer la règle globale en première ligne, suivie immédiatement d’une exception pour les répertoires racine (!*/) puis des whitelistings spécifiques. Cette séquence garantit que Git explore les dossiers tout en conservant le contrôle granulaire sur les fichiers.

En résumé, ignorer tout par défaut offre une protection forte contre les fuites de configuration locale, mais impose une gouvernance rigoureuse du .gitignore. Les équipes doivent peser la réduction du bruit contre le coût de maintenance avant d’adopter ce modèle.