Pull Request: vad det är, skapandeprocess och kodgranskning

Vad är Pull Request?

Pull Request (PR) — är en formell begäran om att inkludera ändringar från en gren till en annan inom ett distribuerat versionshanteringssystem. PR är en central del av samarbetsutveckling på plattformarna GitHub, GitLab och Bitbucket, och kombinerar koddiskussion, automatisk testning och godkännandeprocess för ändringar.

Namnet “Pull Request” återspeglar operationens kärna: utvecklaren ber (request) ägaren av repositoriet att “dra” (pull) hans ändringar. Termen introducerades av GitHub 2008 — före detta fanns liknande mekanismer i form av patchar och merge request (GitLabs term). Idag är PR de facto-standard för teamutveckling med Git.

Enligt GitHub Octoverse, 2025 kräver 89% av open-source-projekten att PR skapas för att kunna göra ändringar. Inom företagsutveckling når denna siffra 95%. PR har blivit inte bara ett tekniskt verktyg utan en del av utvecklingskulturen: genom PR sker kunskapsöverföring, buggupptäckt och samordning av arkitekturbeslut.

Komponenter i Pull Request

En typisk PR består av rubrik, beskrivning, lista över ändrade filer (diff), kommentarer från granskare och status för CI-kontroller. Varje PR är kopplad till en specifik källgren och mål-gren, och efter sammanslagning kan den automatiskt tas bort.

Hur man skapar Pull Request

Att skapa en PR börjar med att publicera feature-grenen i fjärr-repositoriet. Efter push öppnar utvecklaren PR via plattformens gränssnitt eller via CLI (gh, glab). Låt oss titta på processen med GitHub som exempel.

Push av gren och öppning av PR

Första steget — pusha feature-grenen till fjärr-repositoriet och skapa en Pull Request via webbgränssnittet eller kommandoraden.

# Skapa och pusha feature-gren
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# Skapa PR via GitHub CLI
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

Efter att PR skapats kör GitHub automatiskt CI-pipelines (GitHub Actions), kontrollerar efter konflikter med mål-grenen och bjuder in granskare. PR-beskrivningsmallen kan konfigureras via .github/PULL_REQUEST_TEMPLATE.md så att alla PR innehåller obligatoriska avsnitt: syfte, ändringar, testning, relaterade uppgifter.

Beskrivning och taggning

En kvalitativ PR-beskrivning inkluderar: länk till uppgiften (issue/ticket), kort beskrivning av ändringar, testinstruktioner och lista över relaterade ändringar. Etiketter (bug, feature, refactoring) hjälper till att kategorisera PR, medan assignees och reviewers tilldelas automatiskt via CODEOWNERS.

# Tilldela granskare via CODEOWNERS (fil i roten av repositoriet)
# Exempel .github/CODEOWNERS:
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# Skapa PR med granskartilldelning via gh cli
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS — en standardmekanism i GitHub/GitLab för automatisk tilldelning av granskare baserat på ändrade filer. Till exempel tilldelar ändringar i katalogen src/auth/ automatiskt team-auth och senior-dev som granskare. Detta påskyndar processen och säkerställer att rätt personer ser PR.

Uppdatera PR enligt granskning

Efter att ha fått kommentarer från granskaren gör utvecklaren korrigeringar i samma feature-gren och pushar nya commits — PR uppdateras automatiskt. Det är viktigt att inte skriva om historik (rebase) i en publicerad feature-gren om PR redan är öppen, eftersom detta bryter länkar till specifika commits i kommentarerna.

# Göra ändringar enligt granskarens kommentarer
git checkout feature/biometric-auth
# fixa koden
git commit -m "fix: handle biometric timeout per review"
git push

# PR uppdateras automatiskt
# Efter godkännande — slå samman PR via GitHub-gränssnittet

Kodgranskningsprocess

Kodgranskning — den centrala delen av Pull Request. Granskaren kontrollerar ändringarna för korrekthet, kodstil, säkerhet och arkitektonisk konsistens. En kvalitativ granskning förhindrar inte bara buggar utan sprider också kunskap om kodbasen inom teamet.

Googles Engineering Practices (2025) rekommenderar följande principer för kodgranskning: granskaren måste förstå sammanhanget för ändringarna, ge specifika rekommendationer istället för allmänna anmärkningar och separera tekniska och stilistiska kommentarer. Granskningstiden bör inte överstiga 24 timmar från det att PR skapades.

För mobilutveckling inkluderar kodgranskning specifika kontroller: kompatibilitet med targetSdk, korrekt hantering av lifecycle (Android) / view lifecycle (iOS), frånvaro av minnesläckor (LeakCanary, Instruments), stöd för mörkt tema och lokalisering. Dessa kontroller kan automatiseras via linters och Detekt/ktlint.

Typer av kommentarer

PR-plattformar stöder tre typer av kommentarer: allmänna (till hela PR), radkommentarer (till specifik kodrad) och förslag (suggestions med kod att ersätta). Suggestions gör det möjligt att tillämpa ändringen med ett klick, vilket påskyndar processen och minskar antalet iterationer.

När alla kommentarer är lösta och CI-kontroller har godkänts skickar granskaren ett godkännande (Approved). PR kan slås samman. GitHub och GitLab stöder branch protection-regler: obligatoriskt antal godkännanden, obligatoriska CI-kontroller, förbud mot push till main utan PR. För mobilprojekt inkluderar branch protection även byggkontroll: PR kan inte slås samman om applikationen inte kompileras (gradle build failed / xcodebuild failed).

Konfliktlösning i PR

Merge-konflikter i Pull Request är en vanlig situation vid aktivt teamarbete. Plattformarna erbjuder konfliktlösning via webbgränssnitt (för enkla konflikter) eller rekommenderar lokal lösning. GitHub Actions kontrollerar automatiskt möjligheten till sammanslagning vid varje push till feature-grenen och markerar PR som konflikt om sammanslagning inte är möjlig.

Bästa praxis för Pull Request

Effektiva Pull Requests påskyndar kodgranskning och minskar antalet buggar. En studie av SmartBear (2025) visade att PR upp till 200 rader kod får 2 gånger fler meningsfulla kommentarer än PR över 1000 rader, medan granskningstiden minskar 3 gånger.

• Små PR — optimal storlek 100–300 rader. Dela upp stora PR i logiska delar: varje PR löser en uppgift. Detta förenklar granskning och minskar sannolikheten för konflikter
• Tydlig beskrivning — rubrik enligt Conventional Commits (feat:, fix:, refactor:), PR-brödtext innehåller “vad och varför”, inte “hur” (koden talar för sig själv). Mall: syfte → ändringar → testning → relaterade uppgifter
• Snabb återkoppling — granskning inom 24 timmar. Om PR väntar längre än en dag förlorar teamet sammanhang och antalet konflikter vid sammanslagning ökar
• Automatisering — linters, formatters och tester bör köras automatiskt vid skapande av PR. Tillåt inte sammanslagning av PR med misslyckade CI-kontroller
• Draft PR — använd för tidig arkitekturdialog. Draft PR kräver inte granskning och kan inte slås samman, men gör det möjligt att visa kod för kollegor i ett tidigt skede

Ytterligare praxis: skapa inte PR på fredag kväll (ingen kommer att granska förrän på måndag), be 1–2 personer om granskning (fler saktar ner processen utan att öka kvaliteten), använd squash merge för att komprimera historik före sammanslagning. För mobilprojekt rekommenderas också att lägga till en länk till testbyggen (Firebase App Distribution / TestFlight) i PR-beskrivningen så att granskaren kan kontrollera ändringarna i en fungerande applikation.

Pull Request på olika plattformar

De huvudsakliga plattformarna för att arbeta med Pull Request är GitHub, GitLab och Bitbucket. Trots den gemensamma konceptet har var och en sina särdrag som bör beaktas vid val av verktyg för teamet.

GitHub — den mest populära plattformen med störst community, Actions för CI/CD och ett omfattande ekosystem av applikationer (GitHub Marketplace). GitLab utmärker sig med inbyggd CI/CD och möjlighet till full self-hosted-distribution. Bitbucket är tätt integrerat med Jira och Atlassian-ekosystemet, populärt i företagsmiljöer.

För mobilutveckling bestäms plattformsvalet ofta av CI/CD-möjligheter: GitHub Actions stöder macOS-runners för iOS-byggen, GitLab har inbyggda runners för iOS/Android, Bitbucket integreras väl med Firebase Test Lab. Oavsett plattform förblir PR-processen densamma: gren → granskning → CI → merge.