Pull requests forklart: slik samarbeider du tryggere på Git-prosjekter

Jobber du med kode sammen med andre, vil du før eller siden møte begrepet pull request. For mange føles det i starten som nok et vanskelig Git-ord, men en god arbeidsflyt med pull requests kan gjøre prosjektene dine tryggere, ryddigere og enklere å samarbeide på.

I denne artikkelen får du en praktisk gjennomgang av hva en pull request er, hvorfor den er nyttig, og hvordan du kan bruke den steg for steg i et typisk Git-prosjekt på GitHub eller lignende plattformer.

Hva er en pull request, egentlig?

En pull request (ofte forkortet til PR) er et forslag om å inkludere endringene dine i en annen gren i et Git-repo, ofte hovedgrenen. Du viser frem koden din, ber om tilbakemelding og foreslår at den blir slått sammen når den er klar.

Selve koden ligger allerede i repoet ditt på en egen gren, men pull requesten samler alt rundt endringen på ett sted: differanser i filer, diskusjon, kommentarer, godkjenninger og til slutt selve sammenslåingen.

Hvorfor bruke pull requests i stedet for å pushe rett til main?

Det kan være fristende å jobbe rett i hovedgrenen i små prosjekter, men det har flere ulemper. Feil kan havne direkte i produksjon, det er vanskelig å se hva som endret seg når, og kollegaer får lite innsyn i hva som skjer.

Med pull requests får du en naturlig stopp før kode går inn i hovedløypa. Noen fordeler:

• Kodegjennomgang: Andre kan lese og kommentere endringene dine før de havner i main.
• Bedre historikk: Hver PR har et tydelig formål, som gjør loggen mer forståelig.
• Tryggere deploy: Du kan ha regler for godkjenning og tester før sammenslåing.
• Bättre læring: Kommentarfeltet i PR-en blir et naturlig sted for faglig diskusjon.

Typisk arbeidsflyt med pull request

La oss gå gjennom en vanlig arbeidsflyt slik den ofte ser ut i GitHub, men prinsippet er likt på GitLab, Bitbucket og andre plattformer. Poenget er å gjøre en endring på en egen gren, og så foreslå denne inn i main.

En typisk runde ser slik ut:

1. Oppdatere lokal main-gren
2. Lage en ny gren til endringen din
3. Gjøre og teste endringer lokalt
4. Pushe grenen til fjernrepoet
5. Opprette pull request
6. Få (og gi) tilbakemeldinger
7. Rette opp og oppdatere
8. Slå sammen eller lukke PR-en

Steg 1–3: Ny gren, endring og testing

Først sørger du for at du starter fra en oppdatert hovedgren. Så lager du en egen gren for oppgaven din, for eksempel en ny funksjon eller en feilretting.

Eksempel i terminalen:

Oppdater main:
git checkout main
git pull origin main

Lag og gå til ny gren:
git checkout -b feature/forbedret-sok

Nå gjør du endringene dine, kjører tester lokalt og sørger for at koden faktisk virker før du deler den videre. Når du er fornøyd, legger du til og committer:

git add .
git commit -m "Forbedre søk med filtrering på kategori"

Steg 4–5: Push og opprettelse av pull request

Neste steg er å få grenen din opp til plattformen der repoet ligger, for eksempel GitHub. Det gjør du ved å pushe grenen:

git push -u origin feature/forbedret-sok

Etter dette vil du vanligvis se et forslag i webgrensesnittet om å opprette en ny pull request. Klikk deg inn og fyll ut felt som:

• Tittel: Kort og presis, for eksempel: “Forbedret søk med kategorifilter”.
• Beskrivelse: Forklar hva du har gjort, hvorfor, og eventuelle ting anmelderen må vite.
• Relaterte saker: Lenke til issue eller oppgave om det finnes.

Hva bør stå i en god pull request-beskrivelse?

En god beskrivelse gjør det mye enklere for andre å vurdere koden. Tenk at du svarer på tre spørsmål: hva, hvorfor og hvordan teste.

Du kan for eksempel strukturere beskrivelsen slik:

• Bakgrunn: Kort kontekst for endringen.
• Hva som er gjort: Punktvis liste over viktige endringer.
• Hvordan teste: Konkrete steg for å verifisere at alt virker.
• Kjente begrensninger: Ting du vet ikke er optimalt, men som er bevisste valg.

Kodegjennomgang: slik gir og får du nyttige tilbakemeldinger

Når PR-en er opprettet, kan andre lese gjennom koden og legge igjen kommentarer direkte på linjer i filene eller som generelle kommentarer. Målet er ikke å ta noen, men å gjøre koden og løsningen bedre.

Noen tips for gode tilbakemeldinger:

• Vær konkret: Påpek hva som er uklart eller potensielt feil, og hvorfor.
• Foreslå alternativer i stedet for å bare si at noe er feil.
• Skille mellom smak og reell risiko, for eksempel sikkerhet eller ytelse.

Små grep som gjør pull requesten din lett å lese

Store PR-er er tunge å gjennomgå. Du kan gjøre livet enklere for både deg selv og teamet ved å dele opp arbeidet og være litt bevisst på formen.

Noen enkle vaner hjelper mye:

• Gjør én ting per PR, ikke bland ny funksjon, refaktorering og formatendringer.
• Hold PR-er relativt små, del heller i flere steg der det er mulig.
• Gi commit-meldinger som beskriver hva som endres, ikke bare “fiks” eller “wip”.

Godkjenning, sammenslåing og rydding etterpå

Når tilbakemeldingene er håndtert, tester er grønne og eventuelle krav til godkjenning er oppfylt, kan PR-en slåes sammen. Mange team har regler som krever minst én godkjenning før sammenslåing.

Du kan ofte velge mellom ulike typer sammenslåing, for eksempel klassisk merge-commit, squash eller rebase. Hvilken stil dere bruker, bør avtales i prosjektet slik at historikken blir noenlunde konsistent.

Etter sammenslåing er det lurt å:

• Slette den midlertidige grenen på plattformen.
• Slette lokal gren med git branch -d feature/forbedret-sok når alt er oppdatert.
• Oppdatere lokal main med git pull før du starter neste oppgave.

Typiske fallgruver og hvordan du unngår dem

Noen problemer går igjen når folk begynner å bruke pull requests. Heldigvis er de enkle å få kontroll på med litt rutine og teamavtaler.

Vanlige utfordringer:

• For store PR-er: Del opp arbeidet, og refaktorer gjerne i egne PR-er.
• Konflikter mot main: Oppdater grenen din jevnlig fra main før du oppretter PR.
• Ingen beskrivelser: Lag en enkel PR-mal som alle følger.
• Personlig kritikk: Fokuser på koden og løsningen, ikke personen som har skrevet den.

Oppsummering: gjør pull requests til en god vane

Pull requests er mer enn en teknisk Git-funksjon, de er et rammeverk for tryggere samarbeid om kode. Med egne grener, tydelige beskrivelser og konstruktive tilbakemeldinger får du bedre kvalitet, færre overraskelser og en kodebase som er enklere å videreutvikle.

Start enkelt: lag en egen gren for neste oppgave, opprett en liten PR, og inviter noen til å se over. Etter noen runder vil denne måten å jobbe på føles naturlig, også i små prosjekter der du i utgangspunktet jobber alene.