.gitignore — Le fichier qui vous sauve de committer node_modules

Chaque développeur l'a fait au moins une fois : il a commis par erreur node_modules, a .env un fichier plein de clés API, ou un artefact de construction de 200Mo. La panique est réelle. Le remède est fastidieux. Et tout cela aurait pu être évité avec un seul fichier : .gitignore.

Ce guide explique ce que .gitignore est, comment il fonctionne, ce qu'il faut y mettre, et quelques pièges qui piègent même les développeurs expérimentés.

Qu'est-ce que .gitignore ?

.gitignore c'est un fichier de texte simple qui indique à Git quelles fichiers et dossiers doivent être exclus du contrôle de version. Quand Git voit un chemin listé dans .gitignore, il feint que ce chemin n'existe pas — il ne le mettra pas en stage, ne le commettra pas, ni ne l'affichera dans git status sortie.

Ce fichier se trouve au niveau racine de votre dépôt, bien que vous puissiez aussi placer des fichiers spécifiques au projet dans des sous-dossiers. Les règles dans un fichier placé dans un sous-dossier s'appliquent uniquement à ce dossier et à ses sous-dossiers. .gitignore Pourquoi en avoir un (version courte)

— conserve des secrets, des clés API et des mots de passe dans votre historique Git

• Sécurité La taille du dépôt
• — empêche les fichiers générés et les dépendances de grossir votre dépôt Réduction du bruit
• — empêche les fichiers de configuration de l'éditeur et les fichiers de l'OS de se mêler dans chaque différence Santé de l'équipe
• — chacun clone un dépôt propre et installe les dépendances localement Comment fonctionne la syntaxe

Les règles sont simples, mais présentent quelques cas particuliers non évidents :

Les lignes vides et les lignes commençant par

• sont ignorées (utilisez # pour les commentaires) # Un motif sans slash
• correspond à tout fichier ou dossier ayant ce nom, partout dans le dépôt : ignore tous les fichiers de journal, à chaque niveau *.log Un slash en fin
• correspond uniquement aux dossiers : ignore le dossier, mais pas un fichier nommé dist/ Un slash en début dist
• fixe le motif au niveau racine du dépôt : ignore uniquement un /todo.txt au niveau racine todo.txt Deux étoiles (
• correspond à plusieurs niveaux de dossiers :**) partout dans l'arborescence **/logs correspond (If you meant a different context like "to match" in a broader sense, it remains **coïncider**—but strictly literal: *matches* → *correspond*.) logs/ Un signe d'exclamation (
• négocie un motif, réincluant un fichier précédemment exclu!) Exemple minimal

Les entrées les plus courantes (et pourquoi elles sont importantes)

# Dependencies
node_modules/

# Environment files
.env
.env.local
.env.*.local

# Build output
dist/
build/

# Editor noise
.vscode/
.idea/
*.swp

# OS files
.DS_Store
Thumbs.db

# Logs
*.log
npm-debug.log*

node_modules/

C'est le plus important. Un projet typique Node.js comporte des milliers de fichiers dans

— souvent des centaines de mégaoctets. Aucun de ces fichiers n'appartient au contrôle de version. Quiconque clone votre dépôt exécute node_modules/ et les reconstruit localement à partir de npm install . Ignorez-le toujours. package.json.env et fichiers secrets

Les fichiers d'environnement contiennent des mots de passe de bases de données, des clés API et des tokens de services. Un fichier

commis est un incident de sécurité attendu — GitHub scanne pour des secrets dévoilés, mais aussi des bots. Ignorez le fichier, commettez un .env avec des valeurs de placeholder au lieu de cela, afin que les collègues sachent quelles variables doivent être définies. .env.example dist/ et build/

L'output compilé ou bundlé est dérivé du code source. Votre pipeline CI le reconstruit à chaque déploiement. Commettre des artefacts de construction entraîne des conflits de fusion et des diffs faux qui masquent les vraies modifications du code.

Fichiers d'éditeur et de système d'exploitation

(macOS),

.DS_Store (Windows), Thumbs.db (JetBrains), .idea/ (paramètres VS Code) — ces fichiers sont personnels. Les commettre forcera vos préférences sur tous les autres contributeurs. Utilisez un fichier global .vscode/ pour le bruit spécifique à la machine afin de ne pas avoir à l'ajouter dans chaque projet. ~/.gitignore_global .gitignore global : définissez-le une fois, oublié

Vous pouvez configurer un fichier d'ignorer global qui s'applique à tous les dépôts sur votre machine :

Mettez les fichiers d'éditeur, les déchets de l'OS et les outils personnels là. Réservé le fichier de projet pour les choses que l'équipe entière a décidé d'ignorer — comme

git config --global core.excludesfile ~/.gitignore_global

Le piège des fichiers déjà tracés .gitignore C'est là que les développeurs se retrouvent dans la mauvaise situation : node_modules/ ou dist/.

empêche uniquement les fichiers non tracés d'être ajoutés. Si un fichier est déjà dans l'historique Git, l'ajout dans

ne fait rien. Git continue de le suivre et commet toujours les modifications. .gitignore Pour arrêter de suivre un fichier déjà commis : Après cela, le fichier reste sur le disque, mais Git l'ignore à partir de maintenant. Règles de négation : réinclure des fichiers .gitignore Parfois, vous voulez ignorer un dossier, sauf un fichier spécifique — par exemple, ignorer

mais conserver

# Remove the file from git tracking without deleting it locally
git rm --cached path/to/file

# Or remove a whole directory
git rm -r --cached node_modules/

# Then commit the removal
git commit -m "Stop tracking node_modules"

déjà enregistré :

Une particularité : la négation ne peut pas dénoncer un fichier dans un dossier ignoré. Git s'arrête de descendre dans les dossiers ignorés, donc la règle

n'a jamais l'occasion de s'activer. Vous devez ignorer le contenu au lieu du dossier lui-même : config/ Générer un .gitignore pour votre stack config/defaults.json Vous n'avez pas besoin de le rédiger de zéro.

config/
!config/defaults.json

gitignore.io ! (également disponible à

# Wrong — Git never sees defaults.json inside an ignored directory
config/
!config/defaults.json

# Right — ignore everything in config/ except defaults.json
config/*
!config/defaults.json

) vous permet de choisir votre langage, votre framework et votre éditeur, et de générer un fichier d'ignorer complet instantanément. GitHub propose également des modèles officiels dans son dépôt

github/gitignore — ces modèles sont bien maintenus et couvrent des centaines d'environnements. Pour la plupart des projets web, un point de départ solide combine des modèles pour votre langage (Node, Python, PHP, etc.), votre éditeur (VS Code, JetBrains) et votre système d'exploitation (macOS, Windows). gitignore.ioVérifier ce que Git ignore Deux commandes aident à diagnostiquer une règle d'ignoration inattendue : est particulièrement utile lorsque la règle ne fait pas ce que vous attendez — elle affiche le fichier, le numéro de ligne et le motif responsable.

Référence rapide : feuille de route des motifs

Ce que ça ignore

fichiers partout

# See which files are being ignored in the current directory
git status --ignored

# Find out exactly which rule is causing a file to be ignored
git check-ignore -v path/to/file

git check-ignore -v Seulement

au niveau racine

Modèle	Tout dossier nommé
*.log	Tous .log dossier à tout niveau
/debug.log	Réinclure debug.log même si
logs/	l'atteint logs
**/logs	logs fichiers directement dans
!important.log	(pas dans les sous-dossiers) important.log fichiers partout sous *.log .gitignore — Le fichier qui vous sauve de commettre node_modules 2
doc/*.txt	.txt .gitignore — Le fichier qui vous sauve de commettre node_modules 1 doc/ (pas de sous-dossiers)
doc/**/*.txt	.txt fichiers partout sous doc/

Vous aimerez peut-être aussi