Du har bygget en ny funksjon i en egen branch, og den virker på maskinen din. Du kunne slått den rett inn i main med git merge. Men da er det bare du som har sett koden før den går ut til alle, og en liten regnefeil kan nå tusenvis av brukere før noen oppdager den. En pull request er måten team på GitHub sikrer seg mot det: du ber om å få endringene inn, og noen andre ser over dem først.
Hva en pull request er
En pull request er en forespørsel om å slå én branch sammen med en annen. Den samler alt på ett sted: commitene, hvilke linjer som er endret, en beskrivelse av hvorfor, og kommentarene fra de som går gjennom koden. Når alle er fornøyde, trykker noen merge, og endringene er inne.
Pull requests er en GitHub-funksjon, ikke en del av Git. I terminalen finnes bare git merge. GitLab har det samme under navnet merge request.
Merge direkte eller via pull request
For å slå sammen direkte står du i branchen som skal motta endringene, og drar den andre inn:
- git switch main
- git merge dev
Det går fort, og det er greit i egne prosjekter. I et team er det dårlig praksis, fordi ingen andre har sett koden. Med en pull request skjer den samme sammenslåingen, bare etter at noen har godkjent den. Jo flere øyne som ser på koden, jo færre feil når ut.
Slik lager du en pull request i GitHub
- Commit endringene i branchen din som vanlig.
- Push branchen til GitHub med git push, eller Push origin i GitHub Desktop. En pull request kan bare lages av det som ligger på GitHub.
- Åpne repoet på github.com. Øverst dukker det opp et gult felt om at branchen nylig har fått endringer, med knappen Compare & pull request. Du finner også det samme under fanen Pull requests og New pull request.
- Sjekk retningen. Feltet base er branchen endringene skal inn i, og compare er branchen de kommer fra. Pilen mellom dem peker mot base.
- Skriv en tittel og en beskrivelse av hva endringen gjør og hvorfor.
- Velg en reviewer i sidepanelet, en kollega som skal gå gjennom koden. Du kan også velge hvem som er ansvarlig, legge på etiketter og koble pull requesten til et prosjekt.
- Klikk Create pull request.
Pull requesten får et nummer og status Open. GitHub sjekker med en gang om den kan slås sammen uten konflikter, og viser det nederst på siden.
Ber revieweren om endringer, lager du ikke en ny pull request. Du retter i den samme branchen, committer og pusher, og de nye commitene dukker opp i pull requesten av seg selv. Hele samtalen og alle versjonene ligger da samlet, og revieweren ser nøyaktig hva som er endret siden forrige runde.
Tips: Skriv «Closes #4» i beskrivelsen hvis pull requesten løser issue nummer 4. Når den blir slått sammen, lukkes issuet automatisk.
Skriv en pull request som er lett å godkjenne
Den som skal lese koden din, har sine egne oppgaver. Gjør jobben enkel:
- Hold den liten. En pull request på 50 linjer blir lest nøye. En på 2 000 blir skummet.
- Forklar hvorfor, ikke bare hva. Koden viser hva som er endret. Beskrivelsen må fortelle hvilket problem den løser.
- Si hvordan den kan testes. To linjer om hvor man klikker for å se endringen sparer revieweren for gjetting.
- Bruk utkast. Velger du Create draft pull request, kan andre se arbeidet før det er ferdig, uten at noen tror det er klart for godkjenning.
Slå sammen pull requesten
Når revieweren har godkjent og det ikke er konflikter, klikker noen Merge pull request og Confirm merge. Det bør være revieweren eller den som har ansvaret for prosjektet, ikke deg selv. I mange team har du ikke engang lov til å slå sammen din egen.
Knappen har tre varianter. Vanlig merge beholder alle commitene og legger til en merge-commit. Squash and merge slår alle commitene i pull requesten sammen til én, som gir en ryddig historikk i main. Rebase and merge legger commitene rett etter hverandre uten merge-commit. Er du usikker, holder vanlig merge.
Etterpå tilbyr GitHub å slette branchen. Gjør det. Arbeidet ligger trygt i historikken, og listen over branches holder seg oversiktlig. Lokalt henter du endringene med git switch main og git pull.
Har noen endret de samme linjene i mellomtiden, kan ikke pull requesten slås sammen før konflikten er løst. Det står i Slik løser du en merge-konflikt i Git. Hvordan kollegaen går gjennom koden fra sin side, står i Slik gjør du code review i GitHub, og alle valgene finner du i GitHubs dokumentasjon for pull requests.
Denne videoen er hentet fra kurset Git og GitHub på Utdannet.no. I det fulle kurset slår du først to branches sammen med git merge, gjør det samme med en pull request, og følger deretter et helt løp fra issue til feature-branch, pull request og godkjent code review med to forskjellige brukere.
