gitignore-gids: bestanden uitsluiten en sjablonen gebruiken

Een .gitignore-bestand vertelt Git welke bestanden het moet negeren, en goed gitignore-gebruik voorkomt dat je repository opzwelt met build-output, geheime sleutels en editor-restanten. Zodra bestanden als node_modules/, vendor/, .env of .DS_Store in de geschiedenis belanden, groeit je repo onnodig en publiceer je op een dag misschien per ongeluk iemands wachtwoord. Dit artikel laat de juiste manier zien om bestanden uit te sluiten, de patroonsyntaxis en de fouten die het vaakst worden gemaakt.

Eén regel vooraf: .gitignore werkt alleen op bestanden die nog niet worden bijgehouden (untracked). Een bestand aan de negeerlijst toevoegen nadat je het al hebt gecommit, verwijdert het niet automatisch — dit is de meest voorkomende verwarring, en ik heb er hieronder een eigen kop aan gewijd.

Waar plaats je .gitignore?

In de meeste projecten staat één .gitignore in de hoofdmap van de repository en wordt die zelf gecommit, zodat het hele team dezelfde regels deelt. Maar Git ondersteunt meerdere lagen:

• Hoofd-.gitignore — gedeelde regels voor het hele project; opgenomen in versiebeheer.
• .gitignore in submap — een extra bestand in een willekeurige map geldt alleen voor die map en alles eronder. Paden zijn relatief aan die map.
• .git/info/exclude — regels alleen voor jouw machine; nooit gecommit of gedeeld.
• Globale gitignore — persoonlijke regels die op al je repository's worden toegepast (zie hieronder).

Diepere bestanden, die later worden gelezen, kunnen de bovenliggende overschrijven. Zo kan een .gitignore in een submap met een negatie een regel terug-insluiten die de hoofdmap had uitgesloten.

Patroonsyntaxis

Elke regel is een patroon. Lege regels worden genegeerd en regels die met # beginnen zijn commentaar. De basis:

# Commentaarregel
*.log              # alle .log-bestanden (in elke map)
build/             # een / aan het eind matcht alleen mappen
/config.local      # een / vooraan verankert het patroon aan de repo-hoofdmap
temp?.txt          # ? matcht één enkel teken
cache[0-9].dat     # vierkante haken vormen een tekenbereik
!important.log      # ! negatie: dit bestand toch bijhouden

Belangrijke verschillen:

• * matcht alles behalve een slash (/); ** overschrijdt mapgrenzen. Zo vangt logs/**/*.log de .log-bestanden op elke diepte onder logs.
• Een / vooraan verankert het patroon aan de hoofdmap: /build sluit alleen de build-map in de hoofdmap uit, niet de build-mappen in submappen.
• Een / aan het eind richt zich alleen op mappen: build/ sluit geen bestand met dezelfde naam uit.
• ! sluit een bestand weer in dat door een eerdere regel was uitgesloten — maar als de bovenliggende map volledig genegeerd wordt, helpt de negatie niet, omdat Git nooit in die map kijkt.

Een typisch .gitignore-voorbeeld

In een Laravel + Node-project ziet de hoofd-.gitignore er ongeveer zo uit:

# Afhankelijkheden
/node_modules
/vendor

# Omgeving en geheimen
.env
.env.*
!.env.example

# Build-output
/public/build
/dist

# Logs en tijdelijke bestanden
*.log
/storage/*.key

# Editor en besturingssysteem
.DS_Store
.idea/
.vscode/
Thumbs.db

Let op: .env.* sluit elk omgevingsbestand uit, terwijl de regel !.env.example het voorbeeldsjabloon bewust bijgehouden houdt — nieuwe ontwikkelaars gebruiken het om hun eigen .env in te vullen.

Een al bijgehouden bestand uitsluiten

Stel dat je vergat node_modules/ in het begin te negeren en het hebt gecommit. Het nu aan .gitignore toevoegen is niet genoeg; je moet de bestanden uit Git's tracking halen. De oplossing is ze uit de index te halen zonder ze van de schijf te verwijderen:

git rm -r --cached node_modules
git commit -m "chore: node_modules niet meer bijhouden"

De vlag --cached is cruciaal: de bestanden blijven in je werkmap en verlaten alleen Git's index. Na deze commit treedt de .gitignore-regel in werking en worden de bestanden niet opnieuw toegevoegd. Voor één bestand volstaat git rm --cached bestand.

Globale gitignore: persoonlijke restanten overal het zwijgen opleggen

Bestanden als .DS_Store, .idea/ of *.swp zijn specifiek voor jouw besturingssysteem of editor; ze aan de .gitignore van elk project toevoegen is oneerlijk tegenover je teamgenoten. De juiste aanpak is een globale gitignore:

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

Vervolgens schrijf je je persoonlijke patronen in ~/.gitignore_global. Die regels gelden alleen op jouw machine, in al je repository's, zonder het projectbestand te vervuilen.

Kant-en-klare sjablonen en foutopsporing

Je hoeft niet elke taal vanaf nul te schrijven. De officiële repository github/gitignore bevat kant-en-klare sjablonen voor honderden talen en tools, terwijl gitignore.io een gecombineerd bestand genereert op basis van de gekozen technologieën. Gebruik ze als startpunt en snoei daarna bij voor je project.

Wil je weten waarom een bestand wordt genegeerd, gok dan niet — vraag het Git:

git check-ignore -v dist/app.js

Dit commando toont welke regel van welke .gitignore het bestand heeft uitgesloten. Moet je een genegeerd bestand toch toevoegen, dan kun je het afdwingen met git add -f bestand.

Veelgestelde vragen

Waarom wordt een bestand dat ik aan .gitignore toevoegde toch gecommit?

Hoogstwaarschijnlijk wordt het bestand al bijgehouden. .gitignore werkt alleen op niet-bijgehouden bestanden. Haal het uit de index met git rm --cached bestand en commit daarna; de regel werkt vanaf dat moment.

Hoe neem ik een lege map op in de repo?

Git houdt geen lege mappen bij. De conventie is een leeg bestand met de naam .gitkeep in de map te plaatsen (geen officiële Git-functie, slechts een conventie) en dat bestand te committen, zodat de map behouden blijft.

Ik heb per ongeluk een .env-bestand gepubliceerd — wat nu?

Haal het bestand eerst uit de tracking met git rm --cached .env en voeg het toe aan .gitignore. Maar onthoud dat het in oude commits blijft staan: als het echt geheim was, vervang dan onmiddellijk alle wachtwoorden en tokens erin — de geschiedenis opschonen alleen is geen voldoende garantie.

Je repository's schoon houden is een kleine maar blijvende winst. Wil je je Git-opzet, je deploy-flow of het correct opzetten van een project vanaf dag één samen doornemen, neem dan contact met me op.