Quoi ignorer et quoi commiter

Un bon .gitignore se juge à ses critères, pas à sa longueur. Le critère est unique : une personne qui clone le dépôt de zéro peut-elle recréer le même résultat avec seulement le code et la configuration ? Ce qui peut être recréé est ignoré ; ce qui ne peut pas l'être, ou ce qui fige le résultat, est commité.

Ce qu'il faut ignorer

Type	Exemples	Raison
Sorties de build	`dist/`, `build/`, `target/`, `.o`, `.class`	recréées à partir du code
Dépendances installées	`node_modules/`, `vendor/` (PHP), `.venv/`	réinstallées depuis le manifeste et le lockfile
Caches et journaux	`.cache/`, `.pytest_cache/`, `*.log`, `coverage/`	changent à chaque exécution
Environnement local et secrets	`.env`, `.pem`, `local.properties`, `.tfstate`	propres à chaque personne/environnement ou ne doivent pas fuiter
État d'outils personnels	`.DS_Store`, `*.swp`, `.idea/workspace.xml`	sans rapport avec le projet (gitignore global conseillé)

Ce qu'il faut commiter

Lockfiles : package-lock.json, yarn.lock, pnpm-lock.yaml, Cargo.lock, poetry.lock, uv.lock, Gemfile.lock, composer.lock, go.sum, .terraform.lock.hcl. Ils garantissent que tout le monde installe les mêmes versions. Certains modèles, comme celui d'Angular, ignorent les lockfiles : vérifiez le résultat.
Configurations d'exemple : .env.example, config.example.yml. Elles indiquent les valeurs nécessaires sans contenir de vrais secrets.
Wrappers d'outils de build : gradlew et gradle/wrapper/, mvnw. Vérifiez que le jar du wrapper n'a pas été ignoré par le *.jar du modèle Java.
Réglages d'éditeur convenus par l'équipe : .editorconfig, .vscode/settings.json, .vscode/extensions.json, .idea/codeStyles/. Partager le formatage et le lint facilite les revues.

Des .gitignore dans les sous-répertoires

Le .gitignore n'est pas réservé à la racine. Un .gitignore placé dans un sous-répertoire fonctionne par rapport à ce répertoire et prime sur les fichiers situés au-dessus. Dans un monorepo où chaque paquet a ses propres besoins, un fichier par dossier de paquet est plus lisible.

repo/
├── .gitignore          # commun : .DS_Store, .env, coverage/
├── apps/web/.gitignore # .next/, out/
└── services/api/.gitignore # target/

Conserver des répertoires vides

git suit uniquement des fichiers et n'enregistre pas les répertoires vides. Pour qu'un dossier existe mais que son contenu soit ignoré, comme un dossier de journaux, placez-y un fichier marqueur et réincluez-le avec une négation.

/log/*
!/log/.keep

Les noms .keep ou .gitkeep ne sont pas une fonctionnalité officielle de git, seulement une convention. N'importe quel nom fonctionne. Autre méthode : placer dans le dossier un .gitignore avec le contenu suivant, qui ignore tout sauf lui-même.

*
!.gitignore

En combinant des modèles

La combinaison habituelle est 1 ou 2 langages/frameworks + système + éditeur. Si les règles de système et d'éditeur sont déjà dans le global, vous pouvez les omettre.
Vérifiez l'ordre. Les modèles qui contiennent des négations (Gradle, VisualStudioCode) doivent venir après ceux qui ont des règles larges (Java, Kotlin).
Dédoublonnez en préservant le sens. Répéter une règle ne change pas le comportement mais nuit à la lecture. Le générateur de ce site ne supprime les doublons que s'il n'y a pas de négation entre eux.
Gardez les commentaires de section. Des mois plus tard, il faut savoir d'où vient chaque règle pour pouvoir la retirer sans risque.
Testez. Passez au test de motifs les vrais chemins obtenus avec git ls-files pour vérifier qu'aucun fichier n'est ignoré par erreur (par exemple du code front-end pris dans le lib/ du modèle Python).

Des règles courtes et précises

Des règles trop larges comme *.json avalent aussi les fichiers de configuration. Restreignez le chemin autant que possible (/dist/) et terminez les répertoires par une barre pour les distinguer des fichiers de même nom. Un commentaire d'une ligne au-dessus de la règle pour en donner la raison aide la personne suivante à décider si elle peut la supprimer.