Pull request
Een pull request (vaak afgekort tot PR) is een verzoek van een programmeur om zijn of haar aangepaste code op te laten nemen in de hoofdversie van een softwareproject, nadat die code eerst is bekeken en goedgekeurd door anderen. Het is in feite een formeel voorstel: "ik heb deze wijzigingen gemaakt, wil je ze controleren en, als alles klopt, toevoegen aan het project?"
Een handige vergelijking is die van een gezamenlijk geschreven encyclopedie waarbij niet zomaar iedereen direct in de hoofdtekst mag schrijven. Wie een verbetering wil aanbrengen, schrijft eerst een concepttekst apart op. Een redacteur leest die concepttekst, geeft commentaar, vraagt om aanpassingen, en pas als alles in orde is wordt de tekst overgenomen in het hoofddocument. Bij software werkt een pull request op precies dezelfde manier: de codewijziging wordt apart klaargezet, becommentarieerd, eventueel aangepast, en uiteindelijk pas samengevoegd ("gemerged") met de hoofdversie.
Wat is het precies?
Om pull requests te begrijpen, moet je eerst weten wat Git is: een systeem voor versiebeheer, gemaakt door Linus Torvalds in 2005 voor de ontwikkeling van de Linux-kernel. Git houdt de volledige geschiedenis van een softwareproject bij en laat toe dat meerdere mensen tegelijk aan dezelfde code werken zonder dat ze elkaars werk overschrijven.
Binnen Git werkt men vaak met branches (letterlijk: takken). De hoofdversie van een project heet meestal main of master. Wil iemand een nieuwe functie bouwen of een fout herstellen, dan maakt hij een aparte branch aan, een soort kopie waarin hij vrij kan experimenteren zonder de hoofdversie te verstoren.
Een pull request komt in beeld zodra die persoon zijn wijzigingen wil laten samenvoegen met de hoofdversie. De stappen zijn doorgaans:
1. De ontwikkelaar maakt zijn wijzigingen op een eigen branch (of een eigen kopie van het project, een zogeheten fork) en stuurt die naar een platform als GitHub, GitLab of Bitbucket.
2. Hij opent daar een pull request: een pagina die automatisch het verschil (de "diff") toont tussen zijn branch en de hoofdversie.
3. Collega's of projectbeheerders lezen die diff, plaatsen opmerkingen bij specifieke regels code, en kunnen om aanpassingen vragen.
4. Automatische testprogramma's, ondergebracht in wat continuous integration5. Pas als reviewers akkoord geven en de tests slagen, wordt de pull request "gemerged": de wijzigingen worden definitief onderdeel van de hoofdversie.
Belangrijk om te weten: een pull request is geen onderdeel van Git zelf, maar een functie die hostingplatforms zoals GitHub bovenop Git hebben gebouwd. Git kent van oudsher al een commando git pull, waarmee je wijzigingen van een andere plek ophaalt. De term "pull request" komt daar oorspronkelijk vandaan: in de begindagen van Linux stuurden ontwikkelaars elkaar simpelweg een e-mail met het verzoek "trek mijn wijzigingen binnen" (pull my changes). GitHub goot dat informele gebruik later in een overzichtelijke webinterface, inclusief discussie, commentaar en automatische controles.
Wat wil men ermee bereiken?
Het belangrijkste doel is kwaliteitscontrole. Software die zonder controle wordt toegevoegd, loopt sneller risico op fouten, beveiligingsproblemen of onbedoelde neveneffecten. Door een tweede paar ogen verplicht te stellen voordat code wordt samengevoegd, worden fouten vaker ontdekt vóórdat ze schade aanrichten.
Daarnaast maakt de pull request samenwerking op afstand en in de tijd mogelijk. Bij een opensourceproject werken bijdragers vaak in verschillende tijdzones, kennen ze elkaar niet persoonlijk en werken ze soms onbetaald mee. Een pull request geeft een gestructureerde plek waar discussie, uitleg en besluitvorming zichtbaar en na te lezen zijn, ook maanden later nog.
Er is ook een documentatiefunctie: elke pull request laat zien wélke wijziging is gedaan, waaróm, wie ermee akkoord ging en welke tests zijn uitgevoerd. Dat maakt de geschiedenis van een project traceerbaar, wat belangrijk is bij het opsporen van bugs of bij audits.
Tot slot dwingen platforms via zogeheten "branch protection rules" af dat niemand, ook een projectleider niet, rechtstreeks in de hoofdversie mag schrijven zonder review. Dat voorkomt dat één persoon per ongeluk (of moedwillig) het hele project kan beschadigen.
Voorbeelden uit de praktijk
Kubernetes (oorspronkelijk ontwikkeld bij Google, opensource sinds 2014) is een van de grootste projecten die op GitHub draait. Vanwege het enorme aantal bijdragers gebruikt het project geautomatiseerde systemen, waaronder de bot "Prow", om pull requests te labelen, testen te draaien en te bepalen wie goedkeuring moet geven voordat iets wordt samengevoegd.
Rust, de programmeertaal die oorspronkelijk bij Mozilla ontstond (opensource sinds 2010), gebruikt een merge-bot genaamd "bors" (later opgevolgd door vergelijkbare systemen). Reden: bij zoveel gelijktijdige pull requests kan het zijn dat elke wijziging afzonderlijk werkt, maar de combinatie van twee wijzigingen samen toch iets breekt. De bot test daarom combinaties voordat er definitief wordt samengevoegd.
React, de webontwikkelingsbibliotheek van Meta (opensource sinds 2013), en Visual Studio Code, de opensource-editor van Microsoft (opensource sinds 2015), draaien beide volledig op een pull-request-workflow met verplichte automatische tests voordat iets wordt geaccepteerd.
Een tegenvoorbeeld is nuttig om het onderscheid duidelijk te maken: de Linux-kernel zelf, het project waarvoor Git ooit werd gebouwd, gebruikt tot op de dag van vandaag grotendeels géén GitHub pull requests. Kernelontwikkelaars sturen hun wijzigingen nog steeds als patches via e-maillijsten, met opdrachten als git format-patch en git send-email. Torvalds zelf haalt ("pulled") wel wijzigingen op bij zijn vertrouwde onderhouders, wat feitelijk de oorspronkelijke, letterlijke betekenis van "pull request" is, zonder dat daar een GitHub-webinterface aan te pas komt.
Hoe ver is de techniek?
De onderliggende technologie, Git, is sinds 2005 stabiel en fundamenteel weinig veranderd. De pull-requestfunctionaliteit zoals we die nu kennen, bestaat sinds de begindagen van GitHub (kort na de oprichting in 2008) en is inmiddels op vrijwel elk platform beschikbaar: GitHub noemt het "pull request", GitLab noemt hetzelfde concept een "merge request", en Bitbucket gebruikt weer de term "pull request". Het idee zelf is dus volwassen en breed gestandaardiseerd, ook al verschillen de precieze knopjes en workflow-opties per platform.
Wat wél nog volop in ontwikkeling is, zijn de hulpmiddelen eromheen. "Merge queues", waarbij meerdere pull requests automatisch na elkaar en in combinatie worden getest voordat ze definitief worden samengevoegd, zijn een relatief recente toevoeging op grote platforms. Ook is er sinds 2023-2024 een golf aan AI-ondersteunde codereview: GitHub heeft functionaliteit toegevoegd waarbij Copilot automatisch commentaar geeft op een pull request, en er zijn losse AI-tools van derde partijen die hetzelfde proberen te doen. Deze technologie staat nog in de kinderschoenen: de suggesties zijn niet altijd betrouwbaar, en teams verschillen sterk in hoeveel vertrouwen ze aan zulke automatische beoordelingen geven.
Een blijvend obstakel, vooral bij grote of populaire opensourceprojecten, is dat er simpelweg niet genoeg menselijke reviewers zijn. Het is een bekende klacht onder bijdragers dat een pull request soms weken of maanden op beoordeling moet wachten, wat de motivatie van vrijwillige bijdragers kan drukken.
Wie werken eraan?
GitHub, sinds 2018 eigendom van Microsoft, is het platform waarop het pull-requestconcept groot is geworden en blijft toonaangevend in nieuwe functies zoals merge queues en AI-review. GitLab Inc. biedt een vergelijkbaar, deels opensource alternatief, met name populair bij bedrijven die liever zelf hun infrastructuur beheren. Atlassian is de partij achter Bitbucket, dat vooral wordt gebruikt in combinatie met andere Atlassian-producten zoals Jira.
Git zelf, de onderliggende technologie, wordt onderhouden door een internationale groep vrijwilligers onder leiding van Junio Hamano, die het maintainerschap in 2005 van Torvalds overnam. Dit is geen actief onderzoeksveld met universiteiten of laboratoria; het is een gevestigde, praktische engineeringpraktijk. De belangrijkste "spelers" zijn daarom de commerciële platforms die de tooling bouwen en onderhouden, plus de duizenden opensourceprojecten en bedrijven wereldwijd die de werkwijze in de praktijk toepassen en verfijnen.