Sessie 14: Git Best Practices: Schrijf commits die je later nog snapt

Je kunt Git-commando’s typen. Je code staat op GitHub. Maar er is een verschil tussen “Git gebruiken” en “Git goed gebruiken.”

Deze sessie gaat over de gewoontes die ervaren developers elke dag toepassen. Geen nieuwe commando’s, wel scherpere regels. Aan het einde schrijf je commit messages waar je over een jaar nog iets aan hebt, en werk je met een branching-strategie die je project overzichtelijk houdt.

Wat je vandaag leert

Hoe je een commit message schrijft die iets zegt
Drie simpele regels voor branching
Wat git stash is en wanneer je het gebruikt
De pull-voor-je-pusht regel

Deel 1: Commit messages die iets zeggen

Een slechte commit message ziet er zo uit:

git commit -m "fix"
git commit -m "update"
git commit -m "dingen veranderd"

Over drie maanden kijk je terug. Wat was “fix”? Welke “dingen”? Je weet het niet meer. Je moet door de code spitten om te achterhalen wat er gebeurd is. Dat is tijdverspilling.

De goede commit message: 3 delen

Een professionele commit message heeft drie onderdelen:

1. Een korte samenvatting (max 72 karakters)

Schrijf in het Engels. Begin met een werkwoord in de tegenwoordige tijd. Dit heet “imperative mood”: alsof je een bevel geeft aan de codebase. Denk: “Add”, “Fix”, “Remove”, “Update”, “Refactor”.

Add highscore tracking
Fix star spawning off-screen
Remove unused collision code

2. Een lege regel

3. Een langere uitleg (optioneel, als het nodig is)

Add highscore tracking

Slaat de hoogste score op in highscore.txt. De score wordt
bijgewerkt na elke game-over. Het bestand wordt aangemaakt als
het nog niet bestaat.

Dit vervangt de oude methode waarbij de score alleen in het
geheugen stond en verloren ging bij afsluiten.

De uitgebreide uitleg vertelt waarom je iets veranderd hebt, niet alleen wát. De code zelf laat het “wat” al zien. Het “waarom” is wat je over drie maanden nodig hebt.

Commit message regels op een rij

Doe dit	Niet dit
“Add player health bar”	“added health bar thing”
“Fix collision detection on left wall”	“fix”
“Remove debug print statements”	“cleanup”
Max 72 karakters voor de titel	Een heel verhaal in de titel
Tegenwoordige tijd, Engels	Verleden tijd (“added”, “fixed”)

Waarom Engels? Omdat bijna alle open source-projecten Engels gebruiken. Code is internationaal. Ook je Python-code schrijf je in het Engels (def calculate_score). Je commit messages volgen diezelfde taal.

Waarom tegenwoordige tijd? Een commit beschrijft wat deze wijziging dóet, niet wat jij gedaan hébt. “Add feature” (deze commit voegt een feature toe), niet “Added feature” (ik heb ooit een feature toegevoegd). Git zelf gebruikt ook tegenwoordige tijd: Merge branch 'feature', niet Merged.

Multi-line commits in de terminal

Je kunt een commit message over meerdere regels schrijven door de aanhalingstekens niet te sluiten:

git commit -m "Add highscore tracking

Slaat de hoogste score op in highscore.txt. Het bestand wordt
automatisch aangemaakt bij de eerste game-over."

Let op: je typt het sluitende aanhalingsteken pas op de laatste regel. Alles ertussen is onderdeel van je message.

Wanneer commit je?

Commit vaak. Commit klein.

Niet: drie uur werken, één enorme commit met 47 gewijzigde bestanden. Wel: elke 15 tot 30 minuten een commit, telkens als één logisch stukje af is.

Een vuistregel: als je commit message “en” bevat, is je commit te groot. “Add highscore tracking en fix menu bug en update sprites” → dit moeten drie aparte commits zijn.

Kleine commits maken het makkelijker om:

Te begrijpen wat er wanneer veranderd is
Eén specifieke wijziging terug te draaien zonder andere dingen kapot te maken
Merge conflicts op te lossen (kleine brokjes = minder conflicten)

Deel 2: Branching: drie simpele regels

Je weet al hóe je branches maakt (sessie 12). Nu: wannéér en waaróm.

Regel 1: `master` is altijd werkend

De master-branch is je etalage. Iemand die je repo cloned, moet je code kunnen runnen zonder foutmeldingen. master bevat nooit half-af werk.

Niet oké op master: code met # TODO: dit moet nog af, uitgecommentarieerde functies, experimenten die je “later nog fixet.”

Wel oké op master: werkende code. Punt.

Regel 2: Eén feature, één branch

Een branch doet precies één ding. Niet meer.

Goed: feature/player-health-bar
Slecht: feature/health-bar-and-menu-and-sound-effects

Als je tijdens het werken aan een feature denkt: “Oh, ik kan ook even die menu-bug fixen”: stop. Maak een nieuwe branch voor de bugfix. Merge die eerst. Ga dan verder met je feature.

Regel 3: Branches hebben een korte levensduur

Een branch die langer dan een paar dagen bestaat, wordt een probleem. master verandert intussen, en jouw branch raakt achterop. Hoe langer je wacht met mergen, hoe groter de kans op merge conflicts.

Merge je branch zodra de feature klaar is. Voor kleine dingen (een bugfix van 10 minuten): misschien heb je niet eens een aparte branch nodig.

Branch-naamgeving

Geef branches namen die je over een week nog begrijpt:

feature/highscore-tracking
bugfix/star-spawn-offscreen
experiment/particle-effects

De prefix (feature/, bugfix/, experiment/) vertelt meteen wat voor soort werk er in deze branch zit. Dit is een conventie, geen technische vereiste, maar het helpt.

Deel 3: Handige workflow-commando’s

`git stash`: werk opzij zetten

Stel: je bent bezig op een feature-branch. Je code is half af. Je wil even switchen naar master voor een snelle bugfix, maar je wil je half-affe werk niet committen. Daar is git stash voor:

git stash

Git bewaart al je wijzigingen tijdelijk en zet je working directory terug naar de laatste commit. Je kunt nu switchen, de bugfix doen, committen, en terugkomen:

git switch master
# ... bugfix doen, committen ...
git switch feature-branch
git stash pop

git stash pop haalt je opgeslagen wijzigingen terug. Alles staat weer zoals je het achterliet: half af, maar veilig bewaard.

`git pull --rebase`: een schonere geschiedenis

Normaal doet git pull een merge. Dat maakt een extra merge-commit aan. Soms wil je dat niet; je wil een rechte lijn van commits zonder vertakkingen.

git pull --rebase

Dit haalt de nieuwste commits op en zet jouw lokale commits erbovenop, alsof je ze ná de remote-commits gemaakt hebt. Het resultaat is een lineaire geschiedenis: geen merge-commits die alleen maar “Merge branch ‘master’” zeggen.

Let op: gebruik --rebase alleen op branches die jij alleen gebruikt. Bij gedeelde branches is gewoon git pull (merge) veiliger.

De pull-voor-je-pusht regel

Voordat je git push doet:

git pull

Altijd. Ook al denk je dat niemand anders gepusht heeft. Het kost één seconde en voorkomt dat GitHub je push weigert met “Updates were rejected because the remote contains work that you do not have locally.”

Deze regel geldt vooral als je samenwerkt. Als jij de enige bent die aan een repo werkt, is het risico kleiner, maar de gewoonte is goud waard.

Deel 4: De `.gitignore` die je altijd moet hebben

Elk project heeft bestanden die niet in Git horen. Je .gitignore is je eerste verdedigingslinie tegen per ongeluk wachtwoorden committen.

Minimale .gitignore voor een Python-project:

# Python
__pycache__/
*.pyc
*.pyo

# Virtual environment
venv/
.venv/

# Environment variables (bevat vaak wachtwoorden/keys)
.env

# Jouw editor
.vscode/
.idea/
*.swp
*.swo

# OS-bestanden
.DS_Store
Thumbs.db

Waarom __pycache__/ negeren? Dit zijn gecompileerde Python-bestanden die je programma automatisch aanmaakt. Ze zijn verschillend per Python-versie en per computer. Ze in Git stoppen geeft alleen maar ruis.

Waarom .env negeren? .env-bestanden bevatten vaak geheime sleutels, API-keys, database-wachtwoorden. Die mogen nooit, maar dan ook nooit in Git.

Showcase

Laat aan een coach en een buddy zien:

Je laatste 5 commits, met goeie commit messages.
Je .gitignore-bestand.
Een branch-naam die de feature/prefix-conventie volgt.

Tot de volgende keer!

“Nu werk je professioneel met Git. Maar er is nog één concept dat élk team gebruikt: de pull request. Je code is klaar, maar voor hij in master komt, moet iemand anders hem goedkeuren. Hoe werkt dat? Volgende keer: pull requests, de review-muur waar élke wijziging doorheen moet.”

Neem mee naar huis

Makkelijk: Herschrijf de commit messages van je laatste 5 commits. Gebruik de regels uit deze sessie.
Middel: Maak een branch met de feature/-prefix, werk erin, merge hem terug, en verwijder hem. Doe hetzelfde voor een bugfix/-branch.
Lastig: Gebruik git stash om half werk op te slaan, switch naar master, maak een snelle fix, push, en kom terug naar je feature met git stash pop.
Erg lastig: Maak een situatie waar git pull faalt (clone je repo in twee mappen, maak in beide een andere commit, push de eerste, en probeer de tweede te pushen). Los het op: git pull, merge conflict fixen, en dan pas pushen.