Sessie 15: Coach-notities

Doel van deze sessie

Aan het einde van deze sessie kan een ninja:

Samenwerken met een buddy op dezelfde GitHub-repo (collaborator-toegang).
Een feature-branch pushen naar GitHub.
Een pull request openen met een gestructureerde beschrijving (wat, waarom, hoe testen).
Een PR van een buddy reviewen: diff lezen, specifieke feedback geven op regels, approven of changes requesten.
Feedback verwerken door extra commits te pushen naar de feature-branch.
Een goedgekeurde PR mergen en de branch opruimen (lokaal én op GitHub).

Dit is de laatste sessie van de Git-reeks.

Voorbereiding (45 min vóór de sessie)

Duo’s indelen. Ninjas werken in paren. Bedenk van tevoren wie met wie samenwerkt. Houd rekening met: GitHub-account wel/niet actief, Git-ervaring, leeftijd. Een ervaren ninja met een beginner werkt vaak goed: de ervaren ninja leert door uit te leggen.
WiFi-check. Deze sessie vereist stabiel internet voor alle laptops tegelijk. Test vooraf.
Demo-repo klaarzetten. Zorg voor een repo waarop je de volledige PR-workflow kunt demo’en op de projector: een feature-branch, een PR openen, een comment plaatsen, een PR mergen.
Eigen GitHub-account paraat. Je moet collaborator-uitnodigingen kunnen sturen en accepteren tijdens de demo.
Backup: repo-fork uitleg. Als collaborator-toegang om wat voor reden niet werkt (e-mail niet bereikbaar, permissions-problemen), kun je als fallback de fork-workflow uitleggen. Zie de “Praktische valkuilen”-sectie hieronder.

Tijdsindeling (3 uur)

Tijd	Activiteit
0:00 tot 0:15	Welkom, duo’s indelen. Herhaling: branches, pushes, GitHub
0:15 tot 0:40	Projector: volledige PR-workflow (branch, push, PR openen, reviewen, mergen, opruimen)
0:40 tot 0:55	Duo’s: collaborator-toegang instellen + repo clonen
0:55 tot 1:15	Pauze
1:15 tot 1:55	Ronde 1: auteur bouwt feature, opent PR (reviewer wacht/kijkt mee)
1:55 tot 2:10	Reviewer doet review, geeft feedback
2:10 tot 2:25	Auteur verwerkt feedback, reviewer keurt goed, merge
2:25 tot 2:45	Rollen wisselen: ronde 2
2:45 tot 3:00	Showcase, afsluiting, terugblik op de hele Git/GitHub-reeks

Veelgestelde vragen

“Wat is het verschil tussen een collaborator en een fork?” Collaborator = je hebt direct push-toegang tot de repo. Je werkt op branches in dezelfde repo. Fork = je maakt een kopie van iemands repo naar jouw account. Je werkt in jouw kopie, en opent een PR van jouw fork naar het origineel. Collaborator is makkelijker voor beginners; fork is hoe open source werkt.

“Mijn buddy kan mijn uitnodiging niet accepteren.” Check: heeft de reviewer toegang tot e-mail? GitHub stuurt de uitnodiging per e-mail. Alternatief: de reviewer kan naar https://github.com/AUTEUR_USERNAME/repo-naam/invitations gaan om de uitnodiging direct te accepteren.

“Moet ik elke PR mergen met een merge-commit?” GitHub geeft drie opties: merge commit, squash merge, rebase merge. Voor nu: gebruik de standaard (merge commit). Die bewaart de volledige geschiedenis van je feature-branch. Squash en rebase zijn geavanceerder en leer je later.

“Wat als ik per ongeluk op de verkeerde branch werk?” Check altijd met git status op welke branch je zit voor je begint. Als je al commits hebt gemaakt op de verkeerde branch: git stash je wijzigingen, switch naar de juiste branch, en git stash pop.

“Kan ik een PR terugdraaien na het mergen?” Je kunt een commit terugdraaien met git revert <commit-hash>. Dit maakt een nieuwe commit die de wijzigingen ongedaan maakt. Dit is veiliger dan de geschiedenis herschrijven, vooral op master.

Hints voor Stretch en Expert

Stretch: PR template: GitHub kan een template tonen elke keer als iemand een PR opent. Maak een bestand .github/pull_request_template.md in je repo met daarin:

## Wat

## Waarom

## Hoe testen

GitHub vult dit automatisch in bij elke nieuwe PR.

Expert: Draft PR: Als je een PR vroeg wil openen voor feedback, ook al is de code nog niet af, maak dan een draft PR. Klik op de pijl naast “Create pull request” → “Create draft pull request”. Draft PR’s kunnen niet per ongeluk gemerged worden.

Expert: Review van meerdere commits: In het “Files changed”-tabblad kun je per commit bekijken wat er veranderd is. Klik op de commit-dropdown boven de diff. Dit is handig als een PR meerdere commits heeft en je ze één voor één wil bekijken.

Referaat: terugblik op de volledige reeks

Aan het einde van deze sessie kun je kort terugblikken op wat ninjas in vijf sessies geleerd hebben:

Sessie	Wat je kunt
11	`git init`, `add`, `commit`, `status`, `log`, `diff`, `.gitignore`
12	`branch`, `switch`, `merge`, merge conflicts oplossen
13	GitHub: account, `remote`, `push`, `pull`, `clone`
14	Goeie commit messages, branch-naamgeving, `stash`, pull-voor-push
15	Pull requests: openen, reviewen, feedback verwerken, mergen

Dit is de gereedschapskist van elke professionele developer. Ninjas hoeven niet alles perfect te beheersen, maar ze moeten weten dát het bestaat, en de basis zelf kunnen toepassen.

Praktische valkuilen

Collaborator-toegang werkt niet. Oplossing: gebruik de fork-workflow als fallback. De reviewer forkt de repo van de auteur, cloned de fork, maakt een branch, en opent een PR van de fork naar het origineel. Dit vereist geen collaborator-toegang. Het is iets complexer, maar nuttig om te kennen.
Merge conflicts tijdens PR. Als master veranderd is sinds de feature-branch is afgesplitst, ontstaat er een merge conflict bij het mergen van de PR. GitHub toont een waarschuwing. De auteur moet lokaal master mergen in de feature-branch, het conflict oplossen, en opnieuw pushen. Help ninjas hierbij; merge conflicts in een PR-context zijn verwarrender dan lokale conflicts.
PR’s die te groot zijn. Een PR die 30 bestanden wijzigt, is moeilijk te reviewen. Moedig ninjas aan om PR’s klein te houden: één feature, één PR. Als een feature te groot is, splits hem op in meerdere kleinere PR’s.
Vergeten te pullen na de merge. Na het mergen op GitHub moet de auteur lokaal git pull doen op master. Anders werkt die straks op een verouderde master en ontstaan er problemen bij de volgende branch.