Goedkeuren / Approven: wat is het, approval en code review in Git

Wat is een pull request goedkeuring

Goedkeuring (approval) — is een positieve review van een pull request, wat betekent dat de reviewer de code heeft gecontroleerd, geen kritieke problemen heeft gevonden en de wijzigingen klaar acht voor samenvoeging. In de GitHub-interface is dit de groene knop «Approve» op de PR-pagina. Na goedkeuring kan de auteur (of elke deelnemer met schrijfrechten) de merge uitvoeren.

Het goedkeuringsproces maakt deel uit van de Branch Protection Rules. Repository-eigenaren configureren verplichte vereisten: minimaal aantal goedkeuringen (bijv. 1 of 2), wie kan goedkeuren (code-eigenaren, teamleden) en of de PR opnieuw moet worden goedgekeurd na wijzigingen (Dismiss stale reviews). Zonder het configureren van regels is goedkeuring een optionele stap, maar in professionele teams is het verplicht.

GitLab gebruikt een vergelijkbaar mechanisme genaamd Approval Rules. In GitLab kunt u configureren hoeveel goedkeuringen nodig zijn van verschillende groepen (bijv. 2 van backend-ontwikkelaars en 1 van DevOps). Na ontvangst van alle verplichte goedkeuringen wordt de PR automatisch gedeblokkeerd voor merge onder voorwaarde van een groene CI/CD-pipeline.

Soorten reviews: Approve, Request Changes, Comment

In GitHub en GitLab bestaan drie soorten reviews die een reviewer op een pull request kan achterlaten. Elk type heeft een andere status en gevolgen voor het samenvoegingsproces. Approve — groen, Request Changes — rood, Comment — neutraal grijs. De keuze van het type hangt af van de kwaliteit van de code en de gereedheid van de wijzigingen voor acceptatie.

Approve — de reviewer bevestigt: de code is correct geschreven, voldoet aan standaarden, bevat geen duidelijke fouten en kan worden samengevoegd. Approve betekent niet dat de code ideaal is — alleen dat deze goed genoeg is voor productie. Als er kleine opmerkingen zijn (stijl, naamgeving), kunnen deze als opmerkingen worden achtergelaten zonder de PR te blokkeren.

Request Changes — de reviewer vindt problemen die moeten worden opgelost voor merge: logische fouten, kwetsbaarheden, architectuurschendingen, ontbrekende tests. Na Request Changes wordt de PR geblokkeerd en is een nieuwe goedkeuring van dezelfde reviewer vereist voor deblokkering (indien de optie Dismiss stale reviews is ingeschakeld bij nieuwe commits).

• Approve — code is klaar voor samenvoeging, merge is mogelijk na CI-passage.
• Request Changes — verplichte correcties, PR geblokkeerd tot nieuwe review.
• Comment — algemene opmerking of suggestie zonder de PR te blokkeren.

Goedkeuringsregels configureren in de repository

Branch Protection Rules — is het mechanisme van GitHub voor kwaliteitscontrole van samenvoegingen. Het wordt geconfigureerd in Settings → Branches voor elke beschermde branch (main, develop, release/*). Belangrijkste parameters: aantal verplichte goedkeuringen, code-eigenaren (CODEOWNERS), verplichte CI/CD-controle en verbod op push zonder PR.

De parameter Dismiss stale pull request approvals — verwijdert automatisch goedkeuringen als er een nieuwe commit aan de PR wordt toegevoegd. Dit garandeert dat reviewers precies de codeversie goedkeuren die zal worden samengevoegd. Zonder deze instelling kan de auteur na goedkeuring nieuwe code toevoegen en deze komt in main terecht zonder hercontrole.

CODEOWNERS — een bestand in de hoofdmap van de repository dat verantwoordelijken aanwijst voor verschillende directories. Als de PR bestanden betreft die eigendom zijn van een code-eigenaar, wordt zijn goedkeuring verplicht. CODEOWNERS verdeelt verantwoordelijkheidsgebieden: iOS-ontwikkelaar is verantwoordelijk voor Swift-bestanden, DevOps — voor Docker-configuraties, testers — voor testscenario’s.

# Voorbeeld CODEOWNERS-bestand in repo-hoofdmap

# iOS-ontwikkelaars bezitten Swift-code
*.swift @team/ios-developers

# DevOps bezit CI/CD-configuratie
.github/workflows/* @devops-team

# QA-ingenieurs reviewen tests
**/tests/* @qa-engineers

# Standaardeigenaren voor al het andere
* @tech-leads

Code review voor goedkeuring: wat te controleren

Code review voor goedkeuring — is een systematische controle van de code, geen oppervlakkige blik op de diff. Een kwalitatieve code review omvat controle van architectuur, logica, stijl, tests en beveiliging. Zonder deze controle wordt goedkeuring een formaliteit en geen kwaliteitscontrole-instrument.

Wat eerst wordt gecontroleerd: logica van wijzigingen — lost de code de gestelde taak op, zijn er bijwerkingen, is de afhandeling van randgevallen correct. Tests — dekken de nieuwe tests alle scenario’s, slagen bestaande tests na wijzigingen. Beveiliging — zijn er SQL-injecties, XSS, lekken van gevoelige gegevens.

Wat geen onderwerp van review mag zijn: opmaakstijl (daar zijn linters en formatters voor), vooraf genomen architectuurbeslissingen (deze worden besproken voordat code wordt geschreven). Als de review meer dan 400 regels heeft of langer dan een uur duurt — is dit een signaal dat de taak te groot is en decompositie vereist. Beste praktijken voor reviews — porties van 200–400 regels binnen 24 uur na het maken van de PR.

• Logica — correctheid van de taakoplossing, foutafhandeling, randgevallen.
• Tests — dekking van nieuwe scenario’s, slagen van bestaande, afwezigheid van flaky-tests.
• Beveiliging — afwezigheid van injecties, uitvoerescapes, toegang tot gegevens.
• Prestaties — efficiëntie van algoritmen, overbodige queries, geheugenlekken.
• Documentatie — is documentatie bijgewerkt, zijn opmerkingen bij complexe onderdelen begrijpelijk.

Workflow met goedkeuring in een team

Een typische workflow met goedkeuring in een team van 5–10 ontwikkelaars ziet er als volgt uit: de ontwikkelaar maakt een PR, wijst reviewers aan (meestal 1–2 personen uit het team of code-eigenaren), CI/CD start automatische controles. Na ontvangst van alle verplichte goedkeuringen en groene CI voert de auteur de merge uit. De tijd van PR-creatie tot merge is gemiddeld 2 uur tot 2 dagen, afhankelijk van de complexiteit.

GitHub Actions maken automatisering van merge na goedkeuring mogelijk. Als branch-regels zijn geconfigureerd, blokkeert GitHub zelf merge tot alle voorwaarden zijn vervuld. Sommige teams gebruiken bors-ng of Mergify — bots die automatisch PR’s samenvoegen na ontvangst van alle goedkeuringen en CI-passage. Dit versnelt het proces en elimineert de menselijke factor bij merge.

Moderne benadering — trunk-based development met kortlevende branches. In deze workflow moet goedkeuring binnen enkele uren worden verkregen, anders wordt de taak als verouderd beschouwd en vereist opnieuw synchroniseren met main. Teams met een hoge reviewcultuur streven naar een goedkeuringstijd van niet meer dan 4 werkuren.

Fouten bij goedkeuring en hoe ze te vermijden

De meest voorkomende fout — formele goedkeuring zonder echte codecontrole. Wanneer de PR groot is of de deadline nadert, kan de reviewer op Approve drukken zonder in de wijzigingen te duiken. Dit devalueert het hele code review-proces. Oplossing: stel een limiet in voor de PR-grootte (niet meer dan 400 regels) en gebruik code-analysetools (SonarQube, CodeClimate) voor automatische controle.

De tweede fout — buitensporig strenge goedkeuring. Verwachten van ideale code blokkeert de ontwikkeling. Reviewers eisen soms correctie van stilistische opmerkingen die de kwaliteit niet beïnvloeden. Oplossing: scheid verplichte opmerkingen (blokkerend) en optionele suggesties (opmerkingen) duidelijk. GitHub maakt het mogelijk expliciet aan te geven of een opmerking blokkerend is.

De derde fout — goedkeuring zonder CI/CD-controle. Zelfs als de code er correct uitziet, kan het zijn dat deze niet compileert of faalt op tests. Geconfigureerde Branch Protection blokkeert automatisch merge bij rode CI, maar sommige teams schakelen deze bescherming uit voor snelheid. Oplossing: controleer altijd de CI-status voor goedkeuring en keur nooit een PR met een rode pipeline goed.

• Formele goedkeuring — ontbreken van echte codecontrole. Oplossing: limiet van 400 regels per PR.
• Buitensporige strengheid — blokkering vanwege stilistische opmerkingen. Oplossing: verdeling in blocking en optional.
• Negeren van CI — goedkeuring bij rode pipeline. Oplossing: controleer altijd de status van controles.
• Aanwijzen van auteur — goedkeuring van de PR-auteur. Oplossing: Branch Protection configureren tegen de auteur.