Wat is een .gitignore bestand en hoe gebruik je het?

Question

Accepted Answer

Een **.gitignore** bestand vertelt Git welke bestanden en mappen te **negeren** — niet bij te houden in versiebeheer. Het wordt gebruikt om gegenereerde bestanden, afhankelijkheden, geheimen en omgevingsspecifieke bestanden uit te sluiten die niet moeten worden gecommit.

## Wat .gitignore doet

```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 negeert bestanden die aan deze patronen voldoen — ze verschijnen niet in `git status`, worden niet gestaged en worden niet gecommit.

## Patroon syntaxis

```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
```

## Wat negeren (veelvoorkomende categorieën)

```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)
```

## Waarom het belangrijk is

Begrijpen van `.gitignore` is belangrijk voor het **houden van repositories schoon en veilig**, dus het is essentiële praktische Git-kennis.

Een `.gitignore` bestand sluit bestanden uit die **niet in versiebeheer horen**, wat verschillende praktische behoeften adresseert.

Het houdt repositories schoon door **gegenereerde/afgeleide bestanden** (build-uitvoer, gecompileerde artefacten) en **afhankelijkheden** (`node_modules`, die enorm zijn en opnieuw worden geïnstalleerd vanuit manifestbestanden — ze committen zou de repo opblazen) uit te sluiten — zodat de repository alleen de betekenisvolle bron bevat.

Het sluit **omgevingsspecifieke en persoonlijke bestanden** (OS-rommel zoals `.DS_Store`, editor-configuraties) uit die de repo zouden verstoren en lawaai veroorzaken.

Most kritisch is het essentieel voor **veiligheid**: het uitsluiten van **geheimen** (`.env`-bestanden, referenties, API-sleutels) is essentieel omdat **het committen van geheimen een ernstige beveiligingsfout is** — eenmaal gecommit, zijn geheimen in de repository-geschiedenis (en mogelijk gepusht naar externe/openbare repo's waar ze kunnen worden misbruikt), dus `.gitignore` is een belangrijke verdediging tegen het per ongeluk committen van gevoelige gegevens.

Begrijpen van de **patroon syntaxis** (mappen, wildcards, ontkenning, root-relatief) stelt je in staat om effectieve negeerregels te schrijven, en het kennen van de belangrijke gotcha dat **reeds bijgehouden bestanden moeten worden uitgeschakeld** (`git rm --cached`) voordat `.gitignore` van kracht wordt, voorkomt verwarring.

Aangezien schone repositories (geen gegenereerde bestanden, afhankelijkheden of rommel) en vooral het **niet committen van geheimen** belangrijk zijn voor repository-kwaliteit en -veiligheid, en aangezien `.gitignore` het standaardmechanisme is voor het uitsluiten van bestanden die niet moeten worden bijgehouden, is het begrijpen van `.gitignore` — wat negeren (afhankelijkheden, build-uitvoer en kritiek geheimen), de patroon syntaxis en de gotcha voor uitschakeling — essentieel, frequent toegepaste Git-kennis voor het onderhouden van schone, veilige repositories, met het beveiligingsaspect van het houden van geheimen buiten versiebeheer als bijzonder belangrijk.