Sessie 14: Coach-notities

Doel van deze sessie

Aan het einde van deze sessie kan een ninja:

• Commit messages schrijven met een title (max 72 karakters, imperative mood, Engels) + optionele body.
• Uitleggen waarom master altijd werkend moet zijn.
• Branches organiseren met de feature/-, bugfix/- en experiment/-prefixen.
• git stash en git stash pop gebruiken om half werk opzij te zetten.
• git pull standaard doen voor git push.
• Een goede .gitignore voor Python-projecten onderhouden.

Voorbereiding (30 min vóór de sessie)

• Repo met slechte commits klaarzetten. Maak een demo-repo met een paar slechte commit messages (“fix”, “update”, “wip”). Gebruik deze als “voor”-materiaal om te laten zien hoe onduidelijk de geschiedenis wordt.
• .gitignore-cheatsheet printklaar. Het .gitignore-voorbeeld uit de sessie is een goed referentieblad. Print het uit of zet het op het bord.
• Multi-line commit demo. Laat zien hoe je een multi-line commit message maakt zonder externe editor.

Tijdsindeling (3 uur)

Veelgestelde vragen

“Moet ik élke commit message in het Engels schrijven?” Ja. Code is Engels. Variabelen zijn Engels. Functienamen zijn Engels. Commit messages volgen diezelfde taal. Uitzondering: als je met een volledig Nederlandstalig team werkt en dat is de afspraak. Maar voor open source en portfolio: Engels.

“Wat als ik een fout maak in mijn commit message?” Je kunt de message van je laatste commit aanpassen met git commit --amend. Dit opent een editor. Pas de message aan, sla op, sluit. Let op: als je deze commit al gepusht hebt naar GitHub, moet je git push --force gebruiken. Doe dat alleen op branches die jij alleen gebruikt, nooit op master of gedeelde branches.

“Wanneer gebruik ik git stash vs. een branch?” git stash is voor korte onderbrekingen: “Ik ben bezig, maar moet even switchen voor 5 minuten.” Een branch is voor: “Dit is een apart stuk werk dat meerdere commits nodig heeft.” Vuistregel: als je langer dan 10 minuten weg bent van je huidige werk, maak een branch.

“Hoe weet ik of master ‘werkend’ is?” Run je code. Als hij draait zonder errors en de basisfunctionaliteit doet wat hij moet doen, is hij werkend. Test dit vóór elke merge naar master. Als je een feature-branch merged en er breekt iets op master, dan moet je dat fixen vóór je verder werkt aan iets anders.

Hints voor Stretch en Expert

Stretch: git commit --amend: Pas je laatste commit message aan zonder een nieuwe commit te maken. Alleen lokaal gebruiken, niet na pushen (tenzij --force).

Expert: interactieve rebase: git rebase -i HEAD~3 laat je de laatste 3 commits herordenen, samenvoegen of hernoemen. Krachtig, maar gebruik het niet op gedeelde branches. Dit is de “tijdmachine op steroïden” van Git.

Cliffhanger-script

“Commit messages, branches, .gitignore: dat is jouw gereedschapskist. Maar er is nog één stap tussen jouw feature-branch en master. In élk team, bij élk bedrijf, moet je code door een review voordat hij geaccepteerd wordt. Een pull request. Jij vraagt: ‘Mag dit erin?’ Iemand anders kijkt, geeft feedback, en pas dán gaat je code naar master. Volgende keer: hoe maak je een pull request, en hoe review je die van een ander?”

Praktische valkuilen

1. Commit messages in verleden tijd. “Added feature” is een veelgemaakte fout. Het voelt natuurlijk omdat jij het net gedaan hebt. Maar Git zelf beschrijft commits in tegenwoordige tijd: Merge, niet Merged. Train ninjas om “Add” te typen, niet “Added”.

2. Te grote commits. Ninjas willen vaak “alles in één keer committen”: al het werk van de hele sessie. Moedig aan om elke 15 minuten een commit te maken. Stel voor: “Commit nu even wat je hebt, dan kun je daarna verder experimenteren.”

3. Vergeten .gitignore te committen. .gitignore moet zelf wél in Git. Anders hebben anderen die je repo clonen geen ignore-regels. Dit is een veelvoorkomende beginner-fout: het bestand bestaat lokaal maar is nooit ge-git add en gecommit.