Godkänna / Approva: vad är det, approval och code review i Git

Vad är godkännande av pull request

Godkännande (approval) — är en positiv granskning av en pull request, vilket innebär att granskaren har kontrollerat koden, inte hittat kritiska problem och anser ändringarna redo för sammanslagning. I GitHub-gränssnittet är detta den gröna knappen «Approve» på PR-sidan. Efter godkännande kan författaren (eller vilken deltagare som helst med skrivrättigheter) utföra merge.

Godkännandeprocessen är en del av Branch Protection Rules. Repo-ägare konfigurerar obligatoriska krav: minsta antal godkännanden (t.ex. 1 eller 2), vem som kan godkänna (kodägare, teammedlemmar) och om PR måste godkännas på nytt efter ändringar (Dismiss stale reviews). Utan att konfigurera regler är godkännande ett valfritt steg, men i professionella team är det obligatoriskt.

GitLab använder en liknande mekanism som kallas Approval Rules. I GitLab kan du konfigurera hur många godkännanden som krävs från olika grupper (t.ex. 2 från backend-utvecklare och 1 från DevOps). Efter att ha mottagit alla obligatoriska godkännanden låses PR automatiskt upp för merge under förutsättning av en grön CI/CD-pipeline.

Typer av granskning: Approve, Request Changes, Comment

I GitHub och GitLab finns tre typer av granskning som en granskare kan lämna på en pull request. Varje typ har olika status och konsekvenser för sammanslagningsprocessen. Approve — grön, Request Changes — röd, Comment — neutral grå. Valet av typ beror på kodens kvalitet och ändringarnas beredskap för acceptans.

Approve — granskaren bekräftar: koden är korrekt skriven, följer standarder, innehåller inga uppenbara fel och kan slås samman. Approve betyder inte att koden är idealisk — bara att den är tillräckligt bra för produktion. Om det finns mindre anmärkningar (stil, namngivning) kan de lämnas som kommentarer utan att blockera PR.

Request Changes — granskaren hittar problem som måste åtgärdas före merge: logiska fel, sårbarheter, arkitekturöverträdelser, saknade tester. Efter Request Changes blockeras PR och för upplåsning krävs ett nytt godkännande från samma granskare (om alternativet Dismiss stale reviews är aktiverat för nya commits).

• Approve — koden är redo för sammanslagning, merge är möjlig efter CI.
• Request Changes — obligatoriska korrigeringar, PR blockerad till ny granskning.
• Comment — allmän anmärkning eller förslag utan att blockera PR.

Konfigurera godkännanderegler i repot

Branch Protection Rules — är mekanismen i GitHub för kvalitetskontroll av sammanslagningar. Konfigureras i Settings → Branches för varje skyddad gren (main, develop, release/*). Huvudparametrar: antal obligatoriska godkännanden, kodägare (CODEOWNERS), obligatorisk CI/CD-kontroll och förbud mot push utan PR.

Parametern Dismiss stale pull request approvals — tar automatiskt bort godkännanden om en ny commit läggs till i PR. Detta garanterar att granskare godkänner exakt den kodversion som kommer att slås samman. Utan denna inställning kan författaren lägga till ny kod efter godkännande och den hamnar i main utan ny kontroll.

CODEOWNERS — en fil i repo-roten som utser ansvariga för olika kataloger. Om PR påverkar filer som tillhör en kodägare blir hans godkännande obligatoriskt. CODEOWNERS fördelar ansvarsområden: iOS-utvecklaren ansvarar för Swift-filer, DevOps — för Docker-konfigurationer, testare — för testscenarier.

# Exempel på CODEOWNERS-fil i repo-roten

# iOS-utvecklare äger Swift-kod
*.swift @team/ios-developers

# DevOps äger CI/CD-konfiguration
.github/workflows/* @devops-team

# QA-ingenjörer granskar tester
**/tests/* @qa-engineers

# Standardägare för allt annat
* @tech-leads

Code review före godkännande: vad ska kontrolleras

Code review före godkännande — är en systematisk kontroll av koden, inte en ytlig titt på diff. En kvalitativ code review omfattar kontroll av arkitektur, logik, stil, tester och säkerhet. Utan denna kontroll blir godkännande en formalitet, inte ett verktyg för kvalitetskontroll.

Vad kontrolleras först: logiken i ändringarna — löser koden den givna uppgiften, finns det biverkningar, är hanteringen av gränsfall korrekt. Tester — täcker de nya testerna alla scenarier, passerar befintliga tester efter ändringarna. Säkerhet — finns det SQL-injektioner, XSS, läckage av känsliga data.

Vad inte bör vara föremål för granskning: formateringsstil (för det finns linters och formatters), arkitektoniska beslut som tagits i förväg (de diskuteras innan kod skrivs). Om granskningen har mer än 400 rader eller tar längre tid än en timme — är detta en signal om att uppgiften är för stor och kräver nedbrytning. Bästa praxis för granskning — portioner på 200–400 rader inom 24 timmar efter att PR skapats.

• Logik — korrekthet i uppgiftslösning, felhantering, gränsfall.
• Tester — täckning av nya scenarier, passerande av befintliga, avsaknad av flaky-tester.
• Säkerhet — inga injektioner, utdata-eskapning, åtkomst till data.
• Prestanda — effektivitet hos algoritmer, överflödiga frågor, minnesläckor.
• Dokumentation — är dokumentationen uppdaterad, är kommentarer i komplexa delar förståeliga.

Arbetsflöde med godkännande i teamet

Ett typiskt arbetsflöde med godkännande i ett team på 5–10 utvecklare ser ut så här: utvecklaren skapar en PR, utser granskare (vanligtvis 1–2 personer från teamet eller kodägare), CI/CD startar automatiska kontroller. Efter att ha mottagit alla obligatoriska godkännanden och grön CI utför författaren merge. Tiden från PR-skapande till merge är i genomsnitt 2 timmar till 2 dagar beroende på komplexitet.

GitHub Actions möjliggör automatisering av merge efter godkännande. Om grenregler är konfigurerade blockerar GitHub själv merge tills alla villkor är uppfyllda. Vissa team använder bors-ng eller Mergify — botar som automatiskt slår samman PR efter att alla godkännanden mottagits och CI passerat. Detta snabbar upp processen och eliminerar den mänskliga faktorn vid merge.

Modernt tillvägagångssätt — trunk-based development med kortlivade grenar. I detta arbetsflöde måste godkännande erhållas inom några timmar, annars anses uppgiften föråldrad och kräver ny synkronisering med main. Team med hög granskningskultur strävar efter en godkännandetid på högst 4 arbetstimmar.

Misstag vid godkännande och hur man undviker dem

Vanligaste misstaget — formellt godkännande utan verklig kodkontroll. När PR är stor eller deadline närmar sig kan granskaren trycka på Approve utan att fördjupa sig i ändringarna. Detta devalverar hela code review-processen. Lösning: sätt en gräns för PR-storlek (högst 400 rader) och använd kodanalysverktyg (SonarQube, CodeClimate) för automatisk kontroll.

Andra misstaget — alltför strikt godkännande. Att förvänta sig idealisk kod blockerar utvecklingen. Granskare kräver ibland korrigering av stilistiska anmärkningar som inte påverkar kvaliteten. Lösning: separera tydligt obligatoriska anmärkningar (blockerande) och valfria förslag (kommentarer). GitHub gör det möjligt att uttryckligen ange om en kommentar är blockerande.

Tredje misstaget — godkännande utan CI/CD-kontroll. Även om koden ser korrekt ut kan den inte kompilera eller misslyckas i tester. Konfigurerad Branch Protection blockerar automatiskt merge vid röd CI, men vissa team stänger av detta skydd för hastighet. Lösning: kontrollera alltid CI-status före godkännande och godkänn aldrig en PR med röd pipeline.

• Formellt godkännande — avsaknad av verklig kodkontroll. Lösning: gräns på 400 rader per PR.
• Alltför stor stränghet — blockering på grund av stilistiska anmärkningar. Lösning: uppdelning i blocking och optional.
• Ignorera CI — godkännande vid röd pipeline. Lösning: kontrollera alltid kontrollstatus.
• Utsedda författare — godkännande från PR-författaren. Lösning: konfigurera Branch Protection mot författaren.