Merge Request (MR): wat is het, hoe maak je het en het reviewproces

Wat is Merge Request (MR)?

Merge Request (MR) — verzoek om wijzigingen van de ene Git-tak naar de andere te integreren, dat het proces van codereview en automatische controle start. In tegenstelling tot direct samenvoegen via de console, creëert MR een formele procedure: de ontwikkelaar beschrijft wijzigingen, wijst reviewers toe, start CI/CD en ontvangt feedback voordat wijzigingen worden toegepast. Het is een sleutelelement van GitLab, maar het analoge mechanisme in GitHub heet Pull Request (PR).

Volgens GitLab Documentation, 2026 worden in GitLab jaarlijks meer dan 80 miljoen Merge Requests aangemaakt. Elke MR bevat vier hoofdcomponenten: beschrijving (description) met context van wijzigingen, lijst commits (commits), codeverschil (diff) en discussie (discussion thread). Zonder een van deze elementen wordt MR als onvolledig beschouwd.

Merge Request (MR) lost drie taken op: voorkomt directe wijzigingen in beschermde takken (main, develop), zorgt voor kwaliteitscontrole via review en bewaart de geschiedenis van discussies voor toekomstige ontwikkelaars. In GitLab wordt de MR-status in de interface weergegeven met kleurindicatie: grijs voor Draft, oranje voor wachtend, groen voor Approved, paars voor Merged en rood voor Closed.

Terminologie: MR, PR en CR

Op verschillende Git-platforms wordt Merge Request anders genoemd. GitLab gebruikt „Merge Request” (MR), GitHub — „Pull Request” (PR). Analoog — Change Request (CR) in Gerrit. Alle drie verwijzen naar hetzelfde proces: verzoek om integratie van wijzigingen via codereview. De keuze van de term hangt alleen af van het platform dat in het project wordt gebruikt.

# Maak een tak met wijzigingen
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# MR kan worden aangemaakt via GitLab/GitHub UI of CLI:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR vs PR: wat is het verschil tussen GitLab en GitHub

Merge Request in GitLab en Pull Request in GitHub — zijn functioneel identieke mechanismen met verschillende namen. Het verschil is historisch: GitLab positioneerde zich oorspronkelijk als Self-Hosted alternatief voor GitHub en koos de term „Merge Request” voor het samenvoegproces. GitHub, eerder gelanceerd, gebruikte „Pull Request” — verzoek om wijzigingen naar de hoofdtak te „trekken” (pull).

Volgens GitHub Docs, 2024 ondersteunen beide tools dezelfde functieset: beschrijving met Markdown, toewijzen van reviewers, reageren op specifieke coderegels, controlestatussen en automatisch samenvoegen bij voldoen aan voorwaarden. Verschillen hebben betrekking op de interface en extra mogelijkheden.

Hoe maak je een Merge Request: stapsgewijze handleiding

Het maken van een Merge Request (MR) begint met het publiceren van de tak met wijzigingen in de externe repository. Na push naar GitLab of GitHub verschijnt de knop „Create Merge Request” of „Compare & Pull Request” in de interface. De ontwikkelaar vult de beschrijving in, geeft de doeltak aan (meestal develop of main), wijst reviewers toe en voegt labels toe.

Volgens GitLab Documentation, 2025 bevat een standaard MR een titel tot 72 tekens, een beschrijving met sjabloon (template) en een link naar de taak (issue). De beschrijving moet de vragen beantwoorden: wat is gedaan, waarom, hoe is getest. GitLab ondersteunt het automatisch sluiten van issues bij samenvoegen via de trefwoorden Closes, Fixes, Resolves.

# Voorbeeld van sjabloon .gitlab/merge_request_templates/default.md
## What does this MR do?

[Korte beschrijving van de wijzigingen: wat en waarom]

## How to test

1. Voer uit ./gradlew test
2. Controleer LoginActivity met een testtoken
3. Zorg ervoor dat er geen regressie is in AuthManager

## Related issues

Closes #142

Levenscyclus van MR: van Draft tot Merged

Merge Request (MR) doorloopt vijf statussen in GitLab. De eerste — Draft (concept), gemarkeerd met het voorvoegsel „Draft:” in de titel en blokkeert het samenvoegen. Na voorbereiding verwijdert de ontwikkelaar Draft en gaat MR naar de status Opened — codereview begint en de CI/CD-pipeline wordt gestart.

Volgens GitLab Docs, 2024 bekijken reviewers in de status Opened de diff, laten opmerkingen achter en vragen wijzigingen via Resolve Threads. Wanneer alle discussies zijn gesloten en CI/CD succesvol is, stelt de verantwoordelijke ontwikkelaar Approve in. Daarna kan MR worden samengevoegd met de Merge-knop of wachten op automatisch samenvoegen (Auto-merge).

GitLab ondersteunt drie varianten van eindstatus: Merged (succesvol samengevoegd), Closed (gesloten zonder samenvoegen, bijvoorbeeld bij afzien van een functie) en Reopened (heropend na sluiting). Elke status wordt geregistreerd in de Activity Timeline MR voor audit.

Automatische statussen en triggers

GitLab werkt de status van Merge Request automatisch bij bij gebeurtenissen: bij push van nieuwe commits worden Approvals gereset, bij succesvolle CI-pipeline wordt de status Pipeline passed, bij fout — Pipeline failed (samenvoegen wordt geblokkeerd). Auto-merge kan worden geconfigureerd: MR wordt automatisch samengevoegd na succesvolle CI en ontvangst van alle vereiste goedkeuringen.

• Draft — concept, CI start maar samenvoegen is geblokkeerd
• Opened — klaar voor review, reviewers toegewezen, pipeline actief
• Approved — vereist aantal goedkeuringen ontvangen
• Merged — wijzigingen samengevoegd in doeltak
• Closed — gesloten zonder samenvoegen

Regels voor codereview in Merge Request

Codereview in Merge Request (MR) — verplichte fase in de meeste commerciële projecten. Volgens onderzoeksgegevens van SmartBear, 2023 vermindert codereview met MR het aantal defecten met 30–60% en versnelt het de onboarding van nieuwe ontwikkelaars. Hoofdregel — elke MR wordt gecontroleerd door ten minste één, bij voorkeur twee ontwikkelaars die niet hebben deelgenomen aan het schrijven van de code.

MR-controle omvat vijf criteria: correctheid van logica, naleving van codestijl, testdekking, beveiliging en prestaties. In GitLab kunnen Required Approvals worden geconfigureerd — verplicht aantal goedkeuringen voor samenvoegen, bijvoorbeeld 2 goedkeuringen voor main en 1 voor develop.

Discussie in MR wordt gevoerd in Threads — opmerkingen bij specifieke coderegels. Elke discussie moet resolved (gesloten) zijn voor samenvoegen. Om review te versnellen, wordt aanbevolen de MR-grootte te beperken: 200–400 regels wijzigingen. Volgens Google Research (2022) worden MRs groter dan 400 regels 30% minder efficiënt gecontroleerd.

CI/CD-pipeline in Merge Request

Bij het maken van een Merge Request (MR) wordt automatisch een CI/CD-pipeline gestart. In GitLab gebeurt dit via het bestand .gitlab-ci.yml, in GitHub — via GitHub Actions workflow. De pipeline omvat het bouwen van het project (build), het uitvoeren van unittesten (unit tests), linters (lint), statische analyse (SAST) en controle van code coverage.

Volgens GitLab Blog, 2024 wordt de pipelinestatus direct in MR weergegeven: groen vinkje (passed), rood kruis (failed) of gele cirkel (running). Als de pipeline faalt, blokkeert GitLab de Merge-knop tot herstel. In de instellingen kan „Merge when pipeline succeeds” worden ingeschakeld — automatisch samenvoegen na succesvolle pipeline.

# .gitlab-ci.yml — voorbeeld voor Android-project
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

build:
  stage: build
  script:
    - ./gradlew assembleDebug
  only:
    - merge_requests

Samenvoegmethoden: Squash, Merge Commit, Fast-Forward

GitLab en GitHub bieden drie samenvoegmethoden voor Merge Request. De keuze hangt af van het teambeleid en de gewenste geschiedeniszuiverheid. Merge Commit — maakt een aparte samenvoegcommit aan, met behoud van de volledige geschiedenis van de feature-tak. Squash — combineert alle commits van de tak in één commit op de doeltak. Fast-Forward — past commits lineair toe zonder samenvoegcommit.

Volgens GitLab Docs, 2025 heeft Squash de voorkeur in projecten met een hoge commitdichtheid (20+ commits in één feature-tak). Fast-Forward is verplicht voor Trunk-Based Development. Merge Commit wordt gebruikt in Git Flow om de vertakkingssemantiek te behouden.

• Merge Commit — behoudt geschiedenis, maakt samenvoegcommit, geschikt voor Git Flow
• Squash — combineert alle commits in één, schone geschiedenis, tussenliggende commits gaan verloren
• Fast-Forward — lineaire geschiedenis zonder samenvoegcommit, verplicht in TBD

Beste praktijken: hoe schrijf je een goede MR

Een kwalitatieve Merge Request (MR) verkort de reviewtijd en vermindert het aantal fouten. Eerste regel — één MR lost één taak op. Als wijzigingen meerdere niet-gerelateerde functies betreffen, moeten ze worden opgesplitst in afzonderlijke MRs. Tweede — de MR-titel moet informatief zijn: „Add OAuth2 authentication with Google provider” in plaats van „Fix stuff” of „Update code”.

Volgens Google Engineering Practices, 2024 bevat een goede MR een contextbeschrijving: waarom wijzigingen nodig zijn, hoe ze zijn getest, welke risico's er zijn. De MR-grootte mag niet groter zijn dan 400 regels wijzigingen. Als het volume groter is — moet de taak worden opgesplitst in deeltaken. Voor documentatie en tests zijn uitzonderingen toegestaan, maar met toelichting.

Merge Request (MR) moet automatische tests bevatten voor de nieuwe functionaliteit. In GitLab kan het beleid Coverage Check worden geconfigureerd — MR wordt automatisch geblokkeerd als de codedekking onder de drempel (bijv. 80%) is gedaald. Dit garandeert dat de nieuwe functionaliteit de algehele projectkwaliteit niet verlaagt.

• Eén MR — één taak: decomposeer grote wijzigingen in meerdere kleine MRs
• Beschrijving met sjabloon: gebruik .gitlab/merge_request_templates voor uniformiteit
• Grootte tot 400 regels: grote MRs worden langzamer en met meer fouten gecontroleerd
• Tests verplicht: nieuwe functies moeten worden gedekt door unittesten

MR-beschrijvingssjablonen

GitLab ondersteunt Merge Request-sjablonen via bestanden .gitlab/merge_request_templates/. Het sjabloon bevat secties: wat is gedaan, hoe te testen, gerelateerde taken en checklist. Het gebruik van sjablonen versnelt het maken van MRs en garandeert dat ontwikkelaars belangrijke informatie niet vergeten. In de MR-beschrijving wordt verplicht het gerelateerde issue (Closes #N) vermeld voor het automatisch sluiten van taken bij samenvoegen.