Sessie 15: Pull Requests: De voordeur van je project

Je hebt een feature gebouwd op een branch. Goeie commit messages, netjes gewerkt. Nu wil je je code in master zetten.

Je zou git merge kunnen doen en klaar. Maar in een team werkt dat niet. Iemand anders moet je code eerst bekijken: checken op fouten, op stijl, op dingen die je gemist hebt. Dát is een pull request.

Een pull request (PR) is een verzoek: “Haal mijn wijzigingen binnen.” Je opent hem op GitHub. Je teamgenoten bekijken je code, geven feedback. Jij past dingen aan. Pas als iedereen tevreden is, gaat de code naar master.

In deze sessie maak je je eerste pull request. Je reviewt die van een buddy. En je ervaart hoe écht teamwerk met Git voelt.

Wat je vandaag leert

  • Wat een pull request is en waarom teams het gebruiken
  • Een PR openen op GitHub
  • Je PR updaten na feedback
  • Een PR van iemand anders reviewen
  • Een PR mergen en de branch opruimen

Stap 0: Voorbereiding: werken in duo’s

Vandaag werk je samen met een buddy. Spreek af wie de auteur is (die de feature bouwt) en wie de reviewer is (die de PR bekijkt). Halverwege wissel je om.

De auteur heeft een GitHub-repo nodig waar de reviewer toegang toe heeft. De makkelijkste manier:

  1. De auteur maakt een repo aan op GitHub (public).
  2. De auteur gaat naar Settings → Collaborators → Add people.
  3. De auteur nodigt de reviewer uit met diens GitHub-username.
  4. De reviewer accepteert de uitnodiging (via e-mail of GitHub-notificaties).

Nu kunnen jullie allebei pushen naar dezelfde repo.

Alternatief (zonder collaborator-toegang): de reviewer forkt de repo van de auteur en opent een PR vanaf de fork naar het origineel. Maar vandaag houden we het simpel: directe collaborator-toegang.

Stap 1: Een feature-branch maken en pushen (auteur)

De auteur cloned de repo (als dat nog niet gebeurd is) en maakt een feature-branch:

git clone https://github.com/AUTEUR_USERNAME/ons-samenwerk-project.git
cd ons-samenwerk-project
git switch -c feature/groet-functie

Maak een nieuw bestand:

echo 'def groet(naam):' > groet.py
echo '    return f"Hallo {naam}!"' >> groet.py

Commit en push:

git add groet.py
git commit -m "Add groet functie

Retourneert een begroeting voor de opgegeven naam."
git push -u origin feature/groet-functie

Stap 2: Een pull request openen (auteur)

  1. Ga naar je repo op GitHub.
  2. GitHub toont nu een gele balk: “feature/groet-functie had recent pushes”: klik op Compare & pull request. (Als je de balk niet ziet: klik op het Pull requests-tabblad, dan New pull request, kies base: master ← compare: feature/groet-functie.)
  3. Schrijf een duidelijke titel: “Add groet functie”
  4. Schrijf een beschrijving. Een goede PR-beschrijving heeft drie delen:
## Wat

Een functie `groet(naam)` die een begroeting retourneert.

## Waarom

We hebben een herbruikbare begroeting nodig voor de
gebruikersinterface. Dit voorkomt dat we op meerdere plekken
dezelfde string moeten schrijven.

## Hoe testen

```python
from groet import groet
print(groet("CoderDojo"))  # "Hallo CoderDojo!"
5. Klik **Create pull request**.

Je PR staat nu open. Iedereen met toegang tot de repo kan hem zien. GitHub toont de diff: exact welke regels je hebt toegevoegd (groen) en verwijderd (rood).

## Stap 3: Een PR reviewen (reviewer)

De reviewer opent de PR op GitHub. Dit zijn de stappen van een review:

### 1. Lees de beschrijving

Begrijp je wat deze PR doet? Zo niet, vraag om verduidelijking.

### 2. Bekijk de diff

Klik op het **Files changed**-tabblad. GitHub toont elke gewijzigde regel. Kijk naar:

- **Werkt de code?** Zou je het zelf runnen als je het cloned?
- **Is de stijl consistent?** Dezelfde naamgevingsconventies als de rest van het project?
- **Zijn er fouten?** Typo's, ontbrekende imports, logische fouten?
- **Staan er geen geheimen in?** Wachtwoorden, API-keys, tokens?
- **Is het te begrijpen?** Kan iemand die deze code voor het eerst ziet, volgen wat er gebeurt?

### 3. Geef feedback

Klik op een regel om een comment toe te voegen. Wees specifiek:

**Goeie feedback:**
> In `groet.py` regel 2: wat gebeurt er als `naam` leeg is? Misschien een default-waarde toevoegen?

**Slechte feedback:**
> Dit is niet goed.

### 4. Dien je review in

Klik op **Review changes**. Je hebt drie opties:

- **Comment**: gewoon feedback, geen beslissing.
- **Approve**: de code is goed, mag gemerged worden.
- **Request changes**: er moet iets aangepast worden voor de PR gemerged kan worden.

Bij je eerste review: kies **Approve** als alles er goed uitziet, of **Request changes** als je iets wilt laten aanpassen.

## Stap 4: Feedback verwerken (auteur)

De reviewer heeft een comment achtergelaten. De auteur past de code aan:

```bash
# Zorg dat je op je feature-branch zit
git switch feature/groet-functie

Pas groet.py aan op basis van de feedback. Bijvoorbeeld:

def groet(naam="wereld"):
    return f"Hallo {naam}!"

Commit en push:

git add groet.py
git commit -m "Add default parameter to groet functie"
git push

De nieuwe commit verschijnt automatisch in de PR. De reviewer ziet de update en kan opnieuw kijken.

Stap 5: Mergen en opruimen

Als de reviewer Approved heeft, is het tijd om te mergen.

Op GitHub, in de PR, klik je op Merge pull request. Kies Create a merge commit (de standaardoptie). Klik Confirm merge.

De feature-branch is nu samengevoegd met master. Op GitHub kun je de branch verwijderen met de Delete branch-knop die verschijnt na het mergen.

Lokaal moet je ook opruimen:

git switch master
git pull                      # haal de merge op die net op GitHub gebeurd is
git branch -d feature/groet-functie   # verwijder de lokale branch

Je master is nu up-to-date. Je feature-branch is weg, lokaal én op GitHub. Klaar voor het volgende stuk werk.

De volledige PR-workflow op een rij

1. git switch -c feature/iets        ← Maak een feature-branch
2. Werk, commit, werk, commit
3. git push -u origin feature/iets   ← Push naar GitHub
4. Open een PR op GitHub             ← Vraag om review
5. Reviewer bekijkt, geeft feedback
6. Pas code aan, commit, push        ← Feedback verwerken
7. Reviewer approved
8. Merge de PR op GitHub             ← Code naar master
9. git switch master && git pull       ← Haal master lokaal bij
10. git branch -d feature/iets       ← Ruim de branch op

Een PR van iemand anders reviewen: hoe doe je dat goed?

Een review is niet: “Ziet er goed uit.” Een goeie review is specifiek, constructief en respectvol.

Vragen die je jezelf stelt tijdens een review:

  • Snap ik wat deze code doet? (Zo nee: vraag om betere comments of een duidelijkere beschrijving.)
  • Doet de code wat de PR-beschrijving belooft?
  • Kan dit simpeler?
  • Mist er iets? (Foutafhandeling, edge cases, documentatie)
  • Staan er geheimen, wachtwoorden of persoonlijke data in?
  • Volgt de code de stijl van de rest van het project?

Hoe geef je feedback:

Begin met wat goed is. Wees dan specifiek over wat beter kan. Eindig met een duidelijke conclusie.

Voorbeeld:

De functie werkt precies zoals beschreven. Twee suggesties:

  1. In regel 2: een default-waarde voor naam zou handig zijn.
  2. Overweeg een docstring toe te voegen die uitlegt wat de functie retourneert.

Verder ziet het er goed uit. Als je deze twee dingen aanpast, approve ik hem graag.

Showcase

Wissel van rol met je buddy en doe de hele workflow nog een keer: nu ben jij de reviewer.

Laat aan een coach zien:

  1. Een open pull request op GitHub met een beschrijving.
  2. Minstens één review-comment op een PR van je buddy.
  3. Een succesvol gemergede PR: de feature-code staat nu op master.

Tot de volgende keer!

Dit was de laatste Git-sessie. Wat je nu kunt:

  • Je code versiebeheren met Git (init, add, commit, log, diff)
  • Experimenteren op branches zonder master kapot te maken (branch, switch, merge)
  • Je code online delen via GitHub (push, pull, clone)
  • Professionele commit messages schrijven
  • Samenwerken via pull requests: openen én reviewen

Dit is niet “extra”. Dit is hoe developers élke dag werken. Of je nu games maakt, websites bouwt, of AI traint: Git en GitHub zijn de gereedschappen die je project beheersbaar houden. Gebruik ze.

Neem mee naar huis

  1. Makkelijk: Open een pull request voor een wijziging in een van je eigen projecten.
  2. Middel: Vraag een vriend of familielid om een GitHub-account te maken. Nodig ze uit als collaborator en laat ze een PR reviewen.
  3. Lastig: Draag bij aan een echt open source-project. Zoek op GitHub naar issues met het label good first issue. Fork de repo, maak een fix, en open een PR.
  4. Erg lastig: Bouw een klein project met twee anderen. Gebruik branches, pull requests en reviews. Werk alsof je in een professioneel team zit.