- Générateur de .gitignore

Qu'est-ce qu'un fichier .gitignore

Pour qui : Développeurs, équipes Agile, DevOps, contributeurs open-source, étudiants en informatique.

Le fichier .gitignore est l'un des éléments les plus fondamentaux d'un dépôt Git bien structuré. Placé à la racine d'un projet, il indique à Git quels fichiers et dossiers ne doivent jamais être suivis ni envoyés dans le dépôt distant. Sans lui, chaque développeur risque de commiter des artefacts de build, des identifiants secrets, ou des fichiers spécifiques à son environnement local — rendant la collaboration chaotique.

Pourquoi un .gitignore est indispensable

• 🔒 Sécurité — évite que des clés API, mots de passe, certificats ou fichiers .env soient exposés publiquement
• 📦 Taille du dépôt — les dossiers node_modules/ ou vendor/ peuvent peser plusieurs centaines de Mo
• 🤝 Collaboration — chaque développeur génère ses propres artefacts locaux (cache, logs, fichiers IDE) qui ne concernent pas les autres
• ⚡ Performance Git — moins de fichiers à scanner = git status et git add plus rapides
• 🧹 Propreté des commits — les historiques restent lisibles et pertinents

Exemples de fichiers à toujours ignorer

Syntaxe et règles du .gitignore

La syntaxe du .gitignore est simple mais recèle quelques subtilités importantes à maîtriser pour écrire des règles précises et sans effets de bord.

Règles de base

# Ceci est un commentaire (ligne ignorée)

# Ignorer un fichier précis
secrets.json

# Ignorer tous les fichiers .log
*.log

# Ignorer un dossier entier (le / final est recommandé)
node_modules/

# Ignorer un fichier dans un sous-dossier spécifique
config/local.php

# Ignorer récursivement dans tous les sous-dossiers
**/temp/

# Ignorer les fichiers .env mais pas .env.example
.env
!.env.example

Caractères spéciaux

Priorité des règles

Git applique les règles dans l'ordre : une règle ! (négation) peut ré-inclure un fichier précédemment ignoré. Attention : si un dossier parent est ignoré, ses enfants ne peuvent pas être ré-inclus sans ré-inclure le parent d'abord.

# Exemple de négation correcte
logs/
!logs/important.log

# ⚠️ Ceci ne fonctionnera PAS (le dossier logs/ est ignoré globalement)
logs/
!logs/

Templates par langage et framework

Chaque écosystème génère des artefacts spécifiques. Voici les éléments clés à ignorer pour les stacks les plus populaires.

Node.js & JavaScript

# Dépendances
node_modules/
.pnp
.pnp.js

# Build
dist/
build/
.next/

# Environnement
.env
.env.local
.env.*.local

# Cache
.cache/
.eslintcache
*.tsbuildinfo

# Logs
npm-debug.log*
yarn-debug.log*
yarn-error.log*

Python

# Bytecode
__pycache__/
*.py[cod]
*.pyc

# Environnements virtuels
venv/
.venv/
env/

# Distribution
dist/
build/
*.egg-info/

# Tests
.pytest_cache/
.coverage
htmlcov/

# Jupyter
.ipynb_checkpoints/

Java / Spring Boot

# Compilé
*.class
*.jar
target/
build/

# IDE
.idea/
*.iml

# Logs
*.log
spring.log

# Config locale
application-local.properties

PHP / Laravel

# Vendors
vendor/
node_modules/

# Environnement
.env
.env.backup

# Storage Laravel
storage/framework/cache/
storage/framework/sessions/
storage/framework/views/
storage/logs/

# Build Vite
public/build/

Angular

# Dépendances
node_modules/

# Build Angular CLI
dist/
.angular/

# Tests
coverage/

# Environnement
src/environments/*.local.ts
.eslintcache
*.tsbuildinfo

Bonnes pratiques en équipe

Un .gitignore mal configuré est source de frustrations récurrentes dans une équipe. Voici les pratiques qui font la différence entre un projet bien tenu et un dépôt encombré.

1. Commiter le .gitignore dès le début

Le .gitignore doit être l'un des premiers fichiers commités dans un nouveau projet. Ajouter un .gitignore a posteriori ne supprime pas les fichiers déjà trackés — il faut les désindexer manuellement :

# Supprimer un fichier déjà tracké de l'index Git (sans le supprimer du disque)
git rm --cached node_modules/ -r
git rm --cached .env

# Puis commiter
git add .gitignore
git commit -m "chore: add .gitignore"

2. Ne pas commiter node_modules

C'est l'erreur la plus fréquente chez les développeurs débutants. Le dossier node_modules/ peut contenir des milliers de fichiers pour plusieurs centaines de Mo. Tout collaborateur peut le reconstruire avec npm install depuis le package.json — inutile de le versionner.

3. Utiliser un .env.example

Ignorez .env mais commitez .env.example avec des valeurs vides ou fictives. Chaque développeur sait ainsi quelles variables configurer sans exposer les vraies valeurs :

# .gitignore
.env
.env.local
.env.production

# Inclure le template
!.env.example

# .env.example — à commiter
DATABASE_URL=postgresql://localhost:5432/myapp
SECRET_KEY=your-secret-key-here
API_KEY=your-api-key-here

4. Séparer les patterns globaux des patterns projet

Les fichiers IDE (.idea/, .vscode/) et OS (.DS_Store, Thumbs.db) sont des préférences personnelles — ils n'ont pas leur place dans le .gitignore du projet. Configurez-les dans votre gitignore global :

5. Vérifier l'efficacité des règles

# Vérifier si un fichier est ignoré et pourquoi
git check-ignore -v path/to/file

# Lister tous les fichiers ignorés
git ls-files --others --ignored --exclude-standard

# Simuler un git add pour voir ce qui serait commité
git add -n .

Gitignore global vs local

Git propose deux niveaux de configuration pour les fichiers ignorés. Bien les distinguer évite de polluer les dépôts partagés avec des règles personnelles.

Gitignore local (par projet)

Le fichier .gitignore à la racine d'un dépôt s'applique à ce projet et est partagé avec toute l'équipe via le contrôle de version. Il doit contenir les règles communes à tous les développeurs du projet.

Gitignore global (par utilisateur)

Chaque développeur peut définir un fichier gitignore global qui s'applique à tous ses dépôts locaux, quel que soit le projet. Idéal pour les fichiers IDE et OS :

# Configurer le chemin du gitignore global
git config --global core.excludesFile ~/.gitignore_global

# Exemple de contenu ~/.gitignore_global
.DS_Store
Thumbs.db
.idea/
.vscode/
*.swp
*.swo
*~

Gitignore local non partagé (.git/info/exclude)

Pour ignorer des fichiers uniquement sur votre machine sans modifier le .gitignore du projet, utilisez .git/info/exclude. Ce fichier n'est pas versionné et n'affecte que votre copie locale :

# Dans .git/info/exclude — jamais commité
my-local-experiments/
temp-notes.txt

Intégration dans un pipeline CI/CD

Les systèmes CI/CD (GitHub Actions, GitLab CI, Jenkins) clonent le dépôt et respectent le .gitignore. Assurez-vous que les fichiers de configuration nécessaires au build sont bien commités et non ignorés par erreur :

# ⚠️ À ne PAS ignorer (nécessaires au CI)
# package.json, package-lock.json — pour npm ci
# pom.xml — pour Maven
# Pipfile, requirements.txt — pour pip
# build.gradle — pour Gradle

# À ignorer même en CI
node_modules/  # recréé par npm ci
.env           # injecté via les secrets CI

FAQ — Questions fréquentes

Comment ignorer un fichier déjà commité ?

Ajouter un fichier dans .gitignore ne suffit pas s'il est déjà tracké. Il faut le désindexer avec git rm --cached <fichier> puis commiter le changement. Le fichier restera sur le disque mais ne sera plus suivi par Git.

Peut-on ignorer un dossier mais inclure certains fichiers dedans ?

Oui, avec la négation !. Attention : si le dossier parent est ignoré, ses enfants le sont aussi et la négation ne s'applique pas sans ré-inclure le parent d'abord :

# Ignorer tout logs/ sauf errors.log
logs/
!logs/errors.log

Quelle différence entre .gitignore et .dockerignore ?

Le .dockerignore fonctionne de la même manière mais pour les images Docker — il indique à Docker quels fichiers exclure du contexte de build. Les deux fichiers peuvent coexister dans le même projet avec des contenus différents.

Faut-il ignorer package-lock.json ou yarn.lock ?

Non. Les fichiers de lock doivent être commités pour garantir que tous les développeurs et le CI installent exactement les mêmes versions de dépendances. Seul node_modules/ doit être ignoré.

Comment trouver un .gitignore de référence pour mon projet ?

Le dépôt officiel github/gitignore sur GitHub contient des templates maintenus par la communauté pour la quasi-totalité des langages et frameworks. Vous pouvez aussi générer un .gitignore directement depuis gitignore.io ou utiliser ce générateur AngularForAll pour les stacks les plus courantes.

Mon .gitignore n'ignore pas les fichiers — pourquoi ?

Causes fréquentes : (1) les fichiers sont déjà trackés — utilisez git rm --cached ; (2) il existe un autre .gitignore dans un sous-dossier qui écrase la règle ; (3) la règle contient une erreur de syntaxe — vérifiez avec git check-ignore -v <fichier>.

Peut-on utiliser plusieurs .gitignore dans le même projet ?

Oui. Git charge le .gitignore de chaque répertoire et les règles s'appliquent relativement à ce répertoire. C'est utile dans les monorepos pour définir des règles spécifiques à chaque package ou sous-projet.