Pull request in Git: je gids voor hoe het werkt

Pull requests hebben mijn teams geholpen bugs te vermijden, af te stemmen over implementatiekeuzes en van elkaars code te leren. In deze gids laat ik je zien hoe je pull requests op Git-platforms gebruikt om je code veilig te reviewen.

Als je net begint met Git, raad ik aan om onze Introduction to Git- en Introduction to GitHub Concepts-cursussen te volgen om meer te leren over versiebeheer en de verschillen tussen Git en GitHub. Ook vind ik de Git Cheat Sheet, die je kunt downloaden, een handig naslagwerk omdat alle veelvoorkomende Git-termen en -commando’s erin staan.

Wat is een pull request?

Een pull request is in feite een manier om wijzigingen in code voor te stellen. Stel dat je aan een feature werkt of in een aparte branch: met een pull request vraag je om die wijzigingen in de hoofdcodebase te mergen. Dat gebeurt meestal nadat anderen de kans hebben gehad om ze te reviewen. Pull requests zijn een kernonderdeel van samenwerken aan software, zeker in teamverband.

Het is goed om te weten dat dit proces op GitLab een “Merge Request” wordt genoemd. 

Hoe werkt een pull request?

De volgende stappen schetsen de basisworkflow van een pull request:

1. Breng wijzigingen aan in het script (de code) in een featurebranch.
2. Commit deze wijzigingen in je lokale repository.
3. Push de branch naar de remote repository, zoals GitHub.
4. Open een pull request om de wijzigingen voor te stellen aan de mainbranch.
5. Vraag een review aan voor de voorgestelde wijzigingen.
6. Merge of sluit het pull request, afhankelijk van de uitkomst.

Deze workflow geeft elke developer de kans om code te reviewen en mogelijke problemen te vinden voordat code naar productie gaat.

De belangrijkste rollen in het pull-requestproces zijn:

• Contributor: De developer die wijzigingen aanbrengt en het pull request opent.
• Reviewer: De developer die de voorgestelde codewijzigingen reviewt om verbeteringen voor te stellen en de codekwaliteit te bewaken.
• Maintainer: De projectbeheerder die eigenaar is van het project en bevoegd is om pull requests goed te keuren of af te wijzen. 

Ik raad aan om onze cursus Intermediate Git te volgen om te leren hoe je branches maakt in Git en hoe je op afstand samenwerkt met teamleden.

Een pull request maken (met een voorbeeld)

Stel, je ziet een fout in de introductieregel van de README van je project. Je wilt dit corrigeren zonder de mainbranch te raken. Volg dan deze stappen:

Stap 1: Maak een nieuwe branch

Navigeer naar de map van je project en open de terminal om onderstaand commando uit te voeren. Deze regel maakt een nieuwe branch.

git checkout -b fix-readme-typoMogelijk gemaakt door

Stap 2: Breng je wijziging aan

Open het bestand README.md in je code-editor, corrigeer de typefout en sla het bestand op.

Stap 3: Commit de wijzigingen

Stage en commit de wijzigingen met het onderstaande commando:

git add README.md
git commit -m "Fix typo in README"Mogelijk gemaakt door

Stap 4: Push de branch naar GitHub

Upload de branch naar de repository.

git push origin fix-readme-typoMogelijk gemaakt door

Stap 5: Open GitHub en maak een pull request

Open nu je GitHub-account en doe het volgende:

• Navigeer naar je repository op GitHub.

• Selecteer de melding Compare & pull request voor je gepushte branch.

• Voeg een titel toe, zoals Fix typo in README, en schrijf eventueel een korte beschrijving.

• Kies je basisbranch (meestal main) en vergelijk die met je featurebranch.

Stap 6: Vraag een review aan en dien in

Als je project andere developers omvat, kun je reviewers aanvragen of labels toevoegen als het project die gebruikt. Klik daarna op Create pull request.

Bekijk ons project op Performing a Code Review om te begrijpen hoe je code reviewt en wijzigt voordat je deze naar productie pusht.

Best practices voor pull requests

Dit zijn best practices om kwaliteitsvolle ontwikkeling te borgen bij het maken van pull requests:

• Houd je pull requests klein en overzichtelijk: Begin altijd met één pull request per feature die je wilt voorstellen. Zo kan de reviewer je wijzigingen beter volgen en testen, en verklein je de kans op bugs.
• Schrijf duidelijke commitberichten en beschrijvingen: Geef beschrijvende commitberichten om je edits toe te lichten. Deze context helpt reviewers je intentie te begrijpen zonder door de code te hoeven spitten.  
• Gebruik draft pull requests voor vroege feedback: Is je werk nog niet af maar wil je feedback, maak dan een draft pull request. Dat geeft aan dat je code nog in ontwikkeling is en nodigt uit tot discussie zonder meteen te hoeven mergen.
• Test grondig en deel context: Controleer je wijzigingen altijd dubbel om zeker te zijn dat alles werkt zoals verwacht.

Pull requests in verschillende Git-workflows

Een kort overzicht van hoe uiteenlopende teamsettings pull requests inzetten.

• Featurebranching: Dit is gangbaar bij kleine teams en private repositories. Deze workflow houdt in dat je voor elke feature een nieuwe branch maakt. 

• Forking-workflow: Deze workflow wordt gebruikt in open-sourceprojecten. Contributors forken (kopiëren) de hoofdrepository naar hun account, brengen daar wijzigingen aan en openen vervolgens een pull request naar het origineel.

• GitFlow: Dit is een gestructureerde workflow met langetermijnbranches zoals main, develop, release en hotfix. Het wordt gebruikt door grotere teams met uitgebreidere releasecycli.

Etiquette rond pull requests

Slechte manieren zijn mogelijk, dus bij pull requests hoort ook bepaalde etiquette:

• Wees respectvol en specifiek: Focus op de code, niet op de persoon.
• Houd pull requests gefocust: Voorkom dat je niet-gerelateerde wijzigingen in één pull request stopt. Dit negeren maakt review en feedback onnodig ingewikkeld.
• Reageer doordacht op feedback: Erken goed geschreven code en suggesties voor verbetering.
• Laat pull requests niet te lang liggen: Probeer pull requests altijd zo snel mogelijk te reviewen en af te handelen om updates niet te vertragen.
• Stel vragen: Als iets niet duidelijk is, vraag om verduidelijking in plaats van te veronderstellen — zo voorkom je misverstanden.
• Stel verbeteringen voor: Bied waar mogelijk concrete adviezen of alternatieven in plaats van alleen problemen aan te stippen.

Geavanceerde workflows en best practices voor pull requests

Ben je een ervaren developer en wil je samenwerking soepeler maken, de codekwaliteit verhogen en je pull-requestproces opschalen, dan volgen hier praktische tips om je workflow aan te scherpen.

Slimmere workflows

Verschillende Git-workflows gaan anders om met pull requests. Zoals eerder besproken is featurebranching ideaal voor kleine teams vanwege de eenvoud. Maar naarmate je team groeit kan het onderhoud lastiger worden.

Forking wordt aanbevolen voor open source, maar kan extra werk opleveren bij het syncen en reviewen van externe bijdragen. Evenzo is GitFlow aan te raden bij snel ontwikkeltempo, al kan de complexiteit het proces vertragen. 

Automatisering en integratie

Moderne pull requests hebben CI/CD-checks, die kwaliteitscontroles automatiseren door integratie met continuous integration-tools die tests en linters draaien en previews deployen bij elke PR. Zo wordt alleen code gemerged die aan de vastgestelde standaarden voldoet.

Platforms zoals GitHub Actions en GitLab Pipelines maken ook automatisering mogelijk. Denk aan unit tests draaien, previewomgevingen bouwen en deployen — dit vermindert handwerk en vangt problemen vroegtijdig af.

Reviews optimaliseren

Houd pull requests altijd klein en gefocust, zodat ze snel en grondig gereviewd kunnen worden. Templates met duidelijke velden zoals “Wat is er veranderd” en “Hoe te testen” helpen contributors beknopte, relevante info te geven en maken reviews efficiënter.

Let er ook op dat vragen stellen in plaats van eisen stellen een constructieve dialoog en leren bevordert. Door doorlooptijden voor reviews af te spreken, houd je het proces voorspelbaar en voorkom je vertragingen.

Metrics en moderne tools

Ik raad ook aan om PR-grootte, tijd tot review en mergeratio te volgen om knelpunten te identificeren en je workflow efficiënter te maken. Maak reviews en mergen eenvoudiger met een “stacked pull request”: breek grote features op in kleinere, samenhangende PR’s die op elkaar voortbouwen. 

Daarnaast kun je AI-tools zoals GitHub Copilot of CodeWhisperer integreren bij pull requests. Deze tools helpen om potentiële issues vroeg te signaleren en verbeteringen voor te stellen.

Pull requests vs. merge requests

Op GitHub en GitLab worden Pull Requests (PR) en Merge Requests (MR) door elkaar gebruikt. Hoewel ze hetzelfde doel dienen, gaan de platforms er verschillend mee om.

De tabel hieronder vergelijkt PR’s en MR’s om deze verschillen te benadrukken.

Conclusie

Pull requests zijn onmisbaar voor elk serieus project. Zoals je hebt gezien (en hopelijk nu waardeert) stellen ze teams in staat om code samen te reviewen, te bespreken en te verbeteren.

Blijf je skills als developer verbeteren. Bekijk onze Git Fundamentals- en GitHub Foundations-skilltracks om expert te worden in alles rond Git.