Qu'est-ce qu'un fichier .gitignore et comment l'utiliser ?

Question

Accepted Answer

Un fichier **.gitignore** indique à Git quels fichiers et répertoires **ignorer** — ne pas suivre dans le contrôle de version. Il est utilisé pour exclure les fichiers générés, les dépendances, les secrets et les fichiers spécifiques à l'environnement qui ne doivent pas être validés.

## Ce que .gitignore fait

```text
# .gitignore — patterns of files Git should NOT track
node_modules/          # dependencies (reinstalled from package files, don't commit)
dist/                  # build output (generated, don't commit)
*.log                  # log files
.env                   # ⚠️ SECRETS / environment variables — NEVER commit!
.DS_Store              # OS-specific junk
.vscode/               # editor config (often personal)
build/
coverage/
*.tmp
```

Git ignore les fichiers correspondant à ces motifs — ils n'apparaîtront pas dans `git status`, ne seront pas indexés et ne seront pas validés.

## Syntaxe des motifs

```text
node_modules/    → ignore a directory (and everything in it)
*.log            → ignore all files with a .log extension
!important.log   → EXCEPTION: do NOT ignore this (negation)
/build           → ignore "build" only in the root (leading slash = root-relative)
doc/*.txt        → .txt files in doc/ but not subdirectories
**/temp          → "temp" anywhere in the tree
```

## Quoi ignorer (catégories courantes)

```text
✓ DEPENDENCIES — node_modules/, vendor/ (reinstalled from manifests; huge, don't commit)
✓ BUILD OUTPUT — dist/, build/, *.o (generated from source)
✓ SECRETS — .env, credentials, keys (⚠️ NEVER commit secrets — a serious security issue)
✓ ENVIRONMENT/OS/EDITOR files — .DS_Store, .idea/, .vscode/ (personal/machine-specific)
✓ LOGS, caches, temp files
```

```text
⚠️ Already-tracked files aren't ignored by adding them later — untrack first:
   git rm --cached <file>   (then commit; .gitignore prevents re-adding)
```

## Pourquoi c'est important

Comprendre `.gitignore` est important pour **garder les référentiels propres et sécurisés**, c'est pourquoi c'est une connaissance Git pratique essentielle.

Un fichier `.gitignore` exclut les fichiers qui **ne devraient pas être dans le contrôle de version**, répondant à plusieurs besoins réels.

Il garde les référentiels propres en excluant les **fichiers générés/dérivés** (résultats de compilation, artefacts compilés) et les **dépendances** (`node_modules`, qui sont énormes et réinstallées à partir de fichiers manifeste — les valider bloquerait le dépôt) — de sorte que le référentiel contient uniquement le code source pertinent.

Il exclut les **fichiers spécifiques à l'environnement et personnels** (les fichiers système comme `.DS_Store`, les configurations d'éditeur) qui clutteraient le dépôt et causeraient du bruit.

Surtout, c'est essentiel pour la **sécurité** : exclure les **secrets** (fichiers `.env`, identifiants, clés API) est vital car **valider des secrets est une erreur de sécurité grave** — une fois validés, les secrets sont dans l'historique du référentiel (et potentiellement envoyés aux dépôts distants/publics où ils peuvent être exploités), donc `.gitignore` est une défense clé contre la validation accidentelle de données sensibles.

Comprendre la **syntaxe des motifs** (répertoires, caractères génériques, négation, racine relative) vous permet d'écrire des règles d'exclusion efficaces, et connaître la subtilité importante que les **fichiers déjà suivis doivent être retirés du suivi** (`git rm --cached`) avant que `.gitignore` ne prenne effet prévient une confusion courante.

Puisque les référentiels propres (sans fichiers générés, dépendances ou clutter) et surtout **ne pas valider de secrets** importent pour la qualité du référentiel et la sécurité, et puisque `.gitignore` est le mécanisme standard pour exclure les fichiers qui ne doivent pas être suivis, comprendre `.gitignore` — quoi ignorer (dépendances, résultats de compilation et notamment secrets), la syntaxe des motifs et la subtilité du retrait du suivi — est une connaissance Git essentielle et fréquemment appliquée pour maintenir des référentiels propres et sécurisés, l'aspect sécurité de garder les secrets hors du contrôle de version étant particulièrement important.