Pull request-workflow på GitHub

En pull request (PR) er et forslag om at sammenlægge én gren med en anden. På GitHub opretter den en diskussionstråd, hvor teammedlemmer gennemgår koden, skriver kommentarer, anmoder om ændringer og til sidst godkender sammenlægningen.

Når du har pushet en featuregren til GitHub, vises et gult banner, hvor du kan sammenligne grene og oprette en PR. Klik på det, eller gå til Pull requests → Ny pull request, og vælg dine grene.

En god beskrivelse af en PR forklarer: hvad der er ændret, og hvorfor. Medtag et skærmbillede ved ændringer i brugergrænsefladen. Link til den relaterede issue. Beskriv, hvordan du testede det. Læseren bør ikke være nødt til at læse koden for at forstå hensigten.

Udpeg bestemte teammedlemmer som reviewere. De får en notifikation og kan godkende, anmode om ændringer eller kommentere. De fleste teams kræver mindst én godkendelse, før en sammenlægning.

Kommentarer vises direkte ud for de ændrede linjer. Reviewere kan bede om en afklaring, foreslå en anden fremgangsmåde eller godkende. Svar på hver kommentar — enten med en kodeændring eller med en begrundelse for ikke at ændre noget.

Når en reviewer anmoder om ændringer, pusher du nye commits til den samme gren. PR'en opdateres automatisk. Afslut hver samtale ved at klikke på Løs samtale, når du har håndteret den.

Opret en PR som en kladde for at vise, at arbejdet stadig er i gang. Kladde-PR'er giver stadig mulighed for gennemgang og diskussion, men kan ikke sammenlægges ved en fejl. Skift til Klar, når den er færdig.

Når main udvikler sig under gennemgangen, skal du rebase din gren oven på den nyeste main for at undgå konflikter og sikre, at dine ændringer fungerer sammen med den nye kode.

GitHub tilbyder tre sammenlægningsstrategier: sammenlægningscommit (bevarer alle commits), squash og sammenlæg (én commit pr. PR og en ren main-historik) samt rebase og sammenlæg (lineær historik uden sammenlægningscommit). Teams vælger normalt én strategi for at sikre ensartethed.

Beskyt main ved at kræve PR-gennemgang, kræve at statuskontroller (CI) består og forbyde direkte pushes. Indstil det under GitHub → Settings → Branches.

Hold PR'er små og fokuserede. Brug én PR pr. funktion eller rettelse. Store PR'er er svære at gennemgå. Svar på kommentarer fra gennemgangen inden for en dag. Tak reviewerne. Vær venlig — kodegennemgang er en mulighed for at lære fra sig, ikke en revision.

Push featuregrenen → åbn en PR med en tydelig beskrivelse → anmod om reviewere → håndter feedback med nye commits → hold grenen opdateret med rebase → få godkendelse → sammenlæg. Hold PR'er små, fokuserede og godt beskrevet. Regler for beskyttelse af grene håndhæver kvaliteten på main.