Dit is deel 2 van een driedelige serie over version control, branching en CI/CD. In deel 1 kwamen version control, Git, branching strategieën en versienummering aan bod — de bouwstenen zelf. In dit deel zoom ik in op het onderdeel dat in veel uitleg over branching onderbelicht blijft, terwijl het praktisch gezien het scharnierpunt is van de hele workflow: de merge request.
Merge requests: de plek waar kwaliteit wordt afgedwongen
Wat. Een merge request (MR) — bij GitHub “pull request” genoemd, functioneel identiek — is een verzoek om de wijzigingen uit een branch samen te voegen met een andere branch, meestal de hoofdbranch. Het is niet zomaar een technische actie; het is een formeel moment waarop wijzigingen zichtbaar, bespreekbaar en toetsbaar worden vóórdat ze onderdeel worden van de gedeelde codebase.
Waarom. Een merge request bestaat om drie redenen tegelijk:
- Kwaliteitspoort. Het is het moment waarop geautomatiseerde pipelines (linting, tests, security-scans) verplicht kunnen draaien vóórdat er iets wordt samengevoegd.
- Menselijke (peer)review. Code review vindt hier plaats — een tweede paar ogen op de wijziging, gericht op leesbaarheid, ontwerp, edge cases en kennisoverdracht.
- Documentatie en traceerbaarheid. De MR zelf, met beschrijving, discussie en gekoppeld ticket (work-item, story), wordt een permanent, doorzoekbaar verslag van waarom een wijziging is gemaakt — waardevoller dan de code alleen.
Zonder merge requests verdwijnt het enige punt waarop een team gezamenlijk “nee” kan zeggen tegen een wijziging vóórdat die schade kan aanrichten.
Hoe (in GitLab specifiek). GitLab behandelt de merge request niet als los onderdeel, maar als de spil van de hele DevOps-workflow:
- Pipeline-per-MR. Zodra je een MR opent, start GitLab automatisch een pipeline op die specifieke branch. Je ziet direct of de wijziging bouwt, of tests slagen en of aan de kwaliteitseisen wordt voldaan — vóórdat iemand de code hoeft te lezen.
- Draft merge requests. Je kunt een MR als “Draft” markeren wanneer werk nog niet klaar is voor merge, maar je wel vroeg feedback of CI-resultaten wilt — denk aan of de build slaagt, of de unit- en integratietests groen zijn, wat de testdekking is, of de linter en statische code-analyse geen problemen signaleren, en of de security-scan geen kwetsbaarheden vindt. Dit voorkomt dat halfklaar werk per ongeluk wordt samengevoegd, terwijl je wel al vroeg ziet of je op de juiste weg zit.
- Approval rules. GitLab laat je afdwingen dat een MR pas gemerged kan worden na goedkeuring van een bepaald aantal reviewers, of specifiek van een code-owner voor gevoelige bestanden.
- Merge trains. Een functie die veel teams over het hoofd zien: bij hoge merge-frequentie test GitLab wijzigingen in de volgorde waarin ze de hoofdbranch ingaan, alsof ze al zijn samengevoegd — zodat je nooit een “groene” MR hebt die na het samenvoegen alsnog conflicteert met een andere net-samengevoegde wijziging.
- Merge-strategieën. Bij het samenvoegen zelf heb je keuze uit:
- Merge commit — behoudt de volledige geschiedenis, inclusief een expliciete merge-commit;
- Squash merge — voegt alle commits van de branch samen tot één nette commit, handig voor een leesbare hoofdgeschiedenis;
- Fast-forward / rebase — creëert een lineaire geschiedenis zonder merge-commits.
Welke je kiest is een teamafspraak, geen technisch dictaat: squash werkt goed als featurebranches veel “ruis”-commits bevatten (typo’s, kleine fixes); merge commits zijn waardevoller als je de ontwikkelgeschiedenis van een feature wilt kunnen reconstrueren.
| Voor de auteur van een MR | Voor de reviewer |
| Houd het klein: Richt de MR op één ding. Stapel geen work-items of user stories. Grote MR’s krijgen structureel slechtere reviews omdat reviewers de aandacht kwijtraken. | Focus op de code: Richt je op de code en de inhoud, nooit op de persoon. |
| Wees duidelijk: Schrijf een heldere beschrijving: wat verandert er, en waarom. Koppel altijd het bijbehorende backlog-ticket. | Wees constructief: Geef specifieke feedback. “Dit kan korter” is minder bruikbaar dan een concreet en onderbouwd alternatief. Help elkaar om nog beter te worden. |
| Zelfreflectie: Vermeld hoe je de wijziging zelf hebt getest en voer eerst een self-review uit voordat je een ander erbij haalt. | Kijk breder: Let expliciet op security-implicaties en architectuur, niet alleen op de kale functionaliteit. |
Mergeconflicten. Conflicten ontstaan wanneer twee branches dezelfde regel op een verschillende manier hebben gewijzigd. Ze zijn te beperken door:
- regelmatig te pullen, zodat je branch nooit ver achterloopt;
- de wijzigingen van de ander écht te begrijpen voordat je een conflict “oplost”;
- visuele merge-tools te gebruiken bij complexe conflicten;
- gewoon even te communiceren met de andere ontwikkelaar — een conflict is vaak sneller opgelost met een korte vraag dan met tien minuten puzzelen.
Tot slot van dit deel
Met branching, versienummering en nu merge requests op zijn plek, ontbreekt er nog één stuk: hoe komt dit allemaal samen in een werkende CI/CD-pipeline, en hoe verhoudt zich dat tot bestaande change management-processen zoals ITIL? Dat is precies waar deel 3 over gaat: de koppeling met DevOps en CI/CD, branch protection rules concreet gemaakt (met Terraform en een volledig pipeline-voorbeeld), en de relatie tussen ITIL change management en CI/CD.
Schroom niet om contact met mij op te nemen: bertrand@deneveit.nl
Disclaimer: Dit artikel is uitsluitend bedoeld voor informatieve en educatieve doeleinden. De beschreven werkwijzen weerspiegelen ervaringen opgedaan in de praktijk. Het genoemde platform (GitLab) is gekozen ter illustratie van het onderliggende principe; de auteur is niet gelieerd aan GitLab of enige andere partij. Voor toepassing in uw specifieke situatie wordt professioneel advies aanbevolen. Dit artikel is tot stand gekomen met assistentie van een AI-systeem. De technische implementatie, inhoudelijke keuzes, conclusies en eindredactie zijn volledig van de auteur.
Photo by Florian Olivo on Unsplash