Pull Request: wat is het, het maakproces en code review

Wat is een Pull Request?

Pull Request (PR) — is een formeel verzoek om wijzigingen van de ene tak naar de andere op te nemen in een gedistribueerd versiebeheersysteem. PR is het centrale element van collaborative development op GitHub, GitLab en Bitbucket, en combineert codew discussie, automatisch testen en het goedkeuringsproces van wijzigingen.

De naam „Pull Request” weerspiegelt de essentie van de operatie: de ontwikkelaar vraagt (request) de eigenaar van de repository om zijn wijzigingen „binnen te halen” (pull). De term werd in 2008 door GitHub geïntroduceerd — daarvoor bestond een soortgelijk mechanisme in de vorm van patches en merge request (GitLab-term). Tegenwoordig is PR de facto standaard voor teamwerk met Git.

Volgens GitHub Octoverse, 2025 vereist 89% van de opensourceprojecten het aanmaken van een PR om wijzigingen door te voeren. In bedrijfsontwikkeling bereikt dit cijfer 95%. PR is niet alleen een technisch hulpmiddel geworden, maar een onderdeel van de ontwikkelcultuur: via PR vindt kennisoverdracht, bugdetectie en afstemming van architectuur beslissingen plaats.

Onderdelen van een Pull Request

Een typische PR bestaat uit een titel, beschrijving, lijst met gewijzigde bestanden (diff), opmerkingen van reviewers en CI-controlemeldingen. Elke PR is gekoppeld aan een specifieke bron- en doeltak en kan na samenvoeging automatisch worden verwijderd.

Hoe maak je een Pull Request

PR aanmaken begint met het publiceren van de featuretak in de externe repository. Na de push opent de ontwikkelaar een PR via de platforminterface of via CLI (gh, glab). Laten we het proces bekijken aan de hand van GitHub.

Tak pushen en PR openen

Eerste stap — push de featuretak naar de externe repository en maak een Pull Request via de webinterface of opdrachtregel.

# Maak en push de featuretak
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# Maak PR via GitHub CLI
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

Na het aanmaken van de PR start GitHub automatisch CI-pijplijnen (GitHub Actions), controleert op conflicten met de doeltak en nodigt reviewers uit. Het PR-beschrijvingssjabloon kan worden geconfigureerd via .github/PULL_REQUEST_TEMPLATE.md, zodat alle PR’s verplichte secties bevatten: doel, wijzigingen, testen, gerelateerde taken.

Beschrijving en tagging

Een kwalitatieve PR-beschrijving bevat: een link naar de taak (issue/ticket), een korte beschrijving van de wijzigingen, testinstructies en een lijst met gerelateerde wijzigingen. Labels (bug, feature, refactoring) helpen om PR’s te categoriseren, en assignees en reviewers worden automatisch toegewezen via CODEOWNERS.

# Wijs reviewers toe via CODEOWNERS (bestand in de hoofdmap van de repository)
# Voorbeeld .github/CODEOWNERS:
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# Maak PR met toewijzing van reviewers via gh cli
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS — een standaardmechanisme van GitHub/GitLab voor het automatisch toewijzen van reviewers op basis van gewijzigde bestanden. Wijzigingen in de map src/auth/ wijzen bijvoorbeeld automatisch team-auth en senior-dev aan als reviewers. Dit versnelt het proces en garandeert dat de juiste mensen de PR zien.

PR bijwerken na review

Na het ontvangen van opmerkingen van de reviewer voert de ontwikkelaar correcties uit in dezelfde featuretak en pusht nieuwe commits — de PR wordt automatisch bijgewerkt. Het is belangrijk om de geschiedenis (rebase) in een gepubliceerde featuretak niet te herschrijven als de PR al open is, omdat dit de links naar specifieke commits in opmerkingen verbreekt.

# Breng wijzigingen aan volgens opmerkingen van de reviewer
git checkout feature/biometric-auth
# corrigeer code
git commit -m "fix: handle biometric timeout per review"
git push

# PR wordt automatisch bijgewerkt
# Na goedkeuring — voeg PR samen via GitHub-interface

Het code reviewproces

Code review — het centrale element van Pull Request. De reviewer controleert wijzigingen op correctheid, codestijl, beveiliging en architectonische samenhang. Kwalitatieve review voorkomt niet alleen bugs, maar verspreidt ook kennis over de codebase binnen het team.

Google Engineering Practices (2025) beveelt de volgende principes voor code review aan: de reviewer moet de context van wijzigingen begrijpen, specifieke aanbevelingen doen in plaats van algemene opmerkingen, en technische en stilistische opmerkingen scheiden. De reviewtijd mag niet langer zijn dan 24 uur na het aanmaken van de PR.

Voor mobiele ontwikkeling omvat code review specifieke controles: compatibiliteit met targetSdk, correcte afhandeling van lifecycle (Android) / view lifecycle (iOS), geen geheugenlekken (LeakCanary, Instruments), ondersteuning voor donkere modus en lokalisatie. Deze controles kunnen worden geautomatiseerd via linters en Detekt/ktlint.

Soorten opmerkingen

PR-platforms ondersteunen drie soorten opmerkingen: algemeen (over de hele PR), inline (over een specifieke coderegel) en suggesties (met vervangende code). Suggesties maken het mogelijk om een wijziging met één klik toe te passen, wat het proces versnelt en het aantal iteraties vermindert.

Nadat alle opmerkingen zijn opgelost en CI-controles zijn doorstaan, stuurt de reviewer een goedkeuring (Approved). De PR kan worden samengevoegd. GitHub en GitLab ondersteunen branch protection rules: verplicht aantal goedkeuringen, verplichte CI-controles, verbod op push naar main zonder PR. Voor mobiele projecten omvat branch protection ook een buildcontrole: de PR kan niet worden samengevoegd als de app niet bouwt (gradle build failed / xcodebuild failed).

Conflicten oplossen in PR

Mergeconflicten in Pull Request zijn een normale situatie bij actief teamwerk. Platforms bieden conflictoplossing via de webinterface (voor eenvoudige conflicten) of adviseren lokale oplossing. GitHub Actions controleert automatisch de samenvoegbaarheid bij elke push naar de featuretak en markeert de PR als conflict als samenvoeging niet mogelijk is.

Beste praktijken voor Pull Request

Effectieve Pull Requests versnellen code review en verminderen het aantal bugs. Onderzoek van SmartBear (2025) toonde aan dat PR’s tot 200 regels code 2 keer meer inhoudelijke opmerkingen krijgen dan PR’s met meer dan 1000 regels, en de reviewtijd wordt 3 keer korter.

• Kleine PR’s — optimale grootte 100-300 regels. Verdeel grote PR’s in logische delen: elke PR lost één taak op. Dit vereenvoudigt de review en vermindert de kans op conflicten
• Duidelijke beschrijving — titel volgens Conventional Commits (feat:, fix:, refactor:), de inhoud van de PR bevat „wat en waarom”, niet „hoe” (code spreekt voor zich). Sjabloon: doel → wijzigingen → testen → gerelateerde problemen
• Snelle feedback — review binnen 24 uur. Als een PR langer dan een dag wacht — verliest het team context, neemt het aantal conflicten bij merge toe
• Automatisering — linters, formatters en tests moeten automatisch worden gestart bij het aanmaken van een PR. Sta geen samenvoeging toe van PR’s met roodgekleurde CI-controles
• Draft PR — gebruik voor vroege discussie over architectuur. Draft PR vereist geen review en kan niet worden samengevoegd, maar maakt het mogelijk om code in een vroeg stadium aan collega’s te tonen

Aanvullende praktijken: maak geen PR op vrijdagavond (niemand zal vóór maandag reviewen), vraag review aan 1-2 personen (meer vertraagt het proces zonder kwaliteitsverbetering), gebruik squash merge voor het comprimeren van de geschiedenis vóór samenvoeging. Voor mobiele projecten wordt ook aanbevolen om in de PR-beschrijving een link naar de testbuild (Firebase App Distribution / TestFlight) toe te voegen, zodat de reviewer wijzigingen in een werkende app kan controleren.

Pull Request op verschillende platforms

De belangrijkste platforms voor het werken met Pull Request zijn GitHub, GitLab en Bitbucket. Ondanks het gemeenschappelijke concept heeft elk platform kenmerken waarmee rekening moet worden gehouden bij het kiezen van een tool voor het team.

GitHub — het populairste platform met de grootste community, Actions voor CI/CD en een uitgebreid ecosysteem van apps (GitHub Marketplace). GitLab onderscheidt zich door ingebouwde CI/CD en de mogelijkheid van volledige self-hosted implementatie. Bitbucket is nauw geïntegreerd met Jira en het Atlassian-ecosysteem, populair in bedrijfsomgevingen.

Voor mobiele ontwikkeling wordt de platformkeuze vaak bepaald door CI/CD-mogelijkheden: GitHub Actions ondersteunt macOS-runners voor het bouwen van iOS, GitLab heeft ingebouwde runners voor iOS/Android, Bitbucket integreert goed met Firebase Test Lab. Ongeacht het platform blijft het PR-proces hetzelfde: tak → review → CI → merge.