Merge Request (MR): vad är det, hur man skapar och granskningsprocessen

Vad är Merge Request (MR)?

Merge Request (MR) — begäran om att integrera ändringar från en Git-gren till en annan, som initierar processen för kodgranskning och automatisk kontroll. Till skillnad från direkt sammanslagning via konsolen skapar MR en formell procedur: utvecklaren beskriver ändringar, tilldelar granskare, startar CI/CD och får feedback innan ändringarna tillämpas. Det är en nyckelelement i GitLab, men den analoga mekanismen i GitHub kallas Pull Request (PR).

Enligt GitLab Documentation, 2026 skapas över 80 miljoner Merge Requests årligen i GitLab. Varje MR innehåller fyra huvudkomponenter: beskrivning (description) med sammanhang för ändringar, lista över commits (commits), skillnad i kod (diff) och diskussion (discussion thread). Utan ett av dessa element anses MR vara ofullständig.

Merge Request (MR) löser tre uppgifter: förhindrar direkta ändringar i skyddade grenar (main, develop), säkerställer kvalitetskontroll genom granskning och bevarar diskussionshistorik för framtida utvecklare. I GitLab visas MR-status i gränssnittet med färgindikering: grå för Draft, orange för väntande, grön för Approved, lila för Merged och röd för Closed.

Terminologi: MR, PR och CR

På olika Git-plattformar kallas Merge Request olika. GitLab använder “Merge Request” (MR), GitHub — “Pull Request” (PR). Analogi — Change Request (CR) i Gerrit. Alla tre betecknar samma process: begäran om integration av ändringar genom kodgranskning. Valet av term beror endast på vilken plattform som används i projektet.

# Skapa en gren med ändringar
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# MR kan skapas via GitLab/GitHub UI eller CLI:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR vs PR: vad är skillnaden mellan GitLab och GitHub

Merge Request i GitLab och Pull Request i GitHub — är funktionellt identiska mekanismer med olika namn. Skillnaden beror på historien: GitLab positionerade sig ursprungligen som ett Self-Hosted-alternativ till GitHub och valde termen “Merge Request” för sammanslagningsprocessen. GitHub, som lanserades tidigare, använde “Pull Request” — begäran om att “dra” (pull) ändringar till huvudgrenen.

Enligt GitHub Docs, 2024 stöder båda verktygen samma funktionsuppsättning: beskrivning med Markdown, tilldelning av granskare, kommentering av specifika kodrader, kontrollstatus och automatisk sammanslagning när villkoren är uppfyllda. Skillnaderna gäller gränssnittet och ytterligare funktioner.

Hur man skapar en Merge Request: steg-för-steg-guide

Att skapa en Merge Request (MR) börjar med att publicera grenen med ändringar i fjärrrepositoryt. Efter push till GitLab eller GitHub visas knappen “Create Merge Request” eller “Compare & Pull Request” i gränssnittet. Utvecklaren fyller i beskrivningen, anger målgrenen (vanligtvis develop eller main), tilldelar granskare och lägger till etiketter (labels).

Enligt GitLab Documentation, 2025 innehåller en standard MR en titel på upp till 72 tecken, en beskrivning med mall (template) och en länk till uppgiften (issue). Beskrivningen bör svara på frågorna: vad har gjorts, varför, hur har det testats. GitLab stöder automatisk stängning av issues vid sammanslagning genom nyckelorden Closes, Fixes, Resolves.

# Exempel på mall .gitlab/merge_request_templates/default.md
## What does this MR do?

[Kort beskrivning av ändringarna: vad och varför]

## How to test

1. Kör ./gradlew test
2. Kontrollera LoginActivity med testtoken
3. Se till att det inte finns någon regression i AuthManager

## Related issues

Closes #142

MR:s livscykel: från Draft till Merged

Merge Request (MR) går igenom fem statusar i GitLab. Den första — Draft (utkast), markeras med prefixet “Draft:” i titeln och blockerar sammanslagning. Efter förberedelse tar utvecklaren bort Draft och MR går till statusen Opened — kodgranskning börjar och CI/CD-pipelinen startar.

Enligt GitLab Docs, 2024 granskare i statusen Opended granskar diffen, lämnar kommentarer och begär ändringar via Resolve Threads. När alla trådar är stängda och CI/CD har slutförts framgångsrikt sätter den ansvariga utvecklaren Approve. Därefter kan MR slås samman med Merge-knappen eller vänta på automatisk sammanslagning (Auto-merge).

GitLab stöder tre varianter av slutstatus: Merged (framgångsrikt sammanslagen), Closed (stängd utan sammanslagning, t.ex. vid avslag av en funktion) och Reopened (återöppnad efter stängning). Varje status loggas i Activity Timeline MR för granskning.

Automatiska statusar och utlösare

GitLab uppdaterar automatiskt statusen för Merge Request vid händelser: vid push av nya commits återställs Approvals, vid framgångsrik CI-pipeline blir statusen Pipeline passed, vid fel — Pipeline failed (sammanslagning blockeras). Auto-merge kan konfigureras: MR slås samman automatiskt efter framgångsrik CI och mottagande av alla nödvändiga godkännanden.

• Draft — utkast, CI startar men sammanslagning blockeras
• Opened — redo för granskning, granskare tilldelade, pipeline aktiv
• Approved — erforderligt antal godkännanden har erhållits
• Merged — ändringarna har slagits samman i målgrenen
• Closed — stängd utan sammanslagning

Regler för kodgranskning i Merge Request

Kodgranskning i Merge Request (MR) — obligatorisk fas i de flesta kommersiella projekt. Enligt forskningsdata från SmartBear, 2023 minskar kodgranskning med MR antalet defekter med 30–60% och påskyndar introduktionen av nya utvecklare. Huvudregel — varje MR granskas av minst en, helst två utvecklare som inte deltog i att skriva koden.

MR-kontroll omfattar fem kriterier: logisk korrekthet, överensstämmelse med kodstil, testtäckning, säkerhet och prestanda. I GitLab kan Required Approvals konfigureras — obligatoriskt antal godkännanden före sammanslagning, t.ex. 2 godkännanden för main och 1 för develop.

Diskussion i MR förs i Threads — kommentarer till specifika kodrader. Varje tråd måste vara resolved (stängd) före sammanslagning. För att påskynda granskning rekommenderas att begränsa MR-storleken: 200–400 rader ändringar. Enligt Google Research (2022) granskas MR större än 400 rader 30% mindre effektivt.

CI/CD-pipeline i Merge Request

När en Merge Request (MR) skapas startas CI/CD-pipelinen automatiskt. I GitLab sker detta via filen .gitlab-ci.yml, i GitHub — via GitHub Actions workflow. Pipelinen omfattar bygge av projektet (build), körning av enhetstester (unit tests), linters (lint), statisk analys (SAST) och kontroll av kodtäckning.

Enligt GitLab Blog, 2024 visas pipelinestatus direkt i MR: grön bock (passed), rött kryss (failed) eller gul cirkel (running). Om pipelinen misslyckas blockerar GitLab Merge-knappen tills korrigering. I inställningarna kan “Merge when pipeline succeeds” aktiveras — automatisk sammanslagning efter framgångsrik pipeline.

# .gitlab-ci.yml — exempel för Android-projekt
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

build:
  stage: build
  script:
    - ./gradlew assembleDebug
  only:
    - merge_requests

Sammanslagningsmetoder: Squash, Merge Commit, Fast-Forward

GitLab och GitHub erbjuder tre sammanslagningsmetoder för Merge Request. Valet beror på teamets policy och önskad historikrenhet. Merge Commit — skapar en separat sammanslagningscommit och bevarar hela historiken för feature-grenen. Squash — slår samman alla commits från grenen till en commit på målgrenen. Fast-Forward — tillämpar commits linjärt utan sammanslagningscommit.

Enligt GitLab Docs, 2025 föredras Squash i projekt med hög commit-täthet (20+ commits i en feature-gren). Fast-Forward är obligatoriskt för Trunk-Based Development. Merge Commit används i Git Flow för att bevara förgreningssemantik.

• Merge Commit — bevarar historik, skapar sammanslagningscommit, lämplig för Git Flow
• Squash — slår samman alla commits i en, ren historik, mellanliggande commits förloras
• Fast-Forward — linjär historik utan sammanslagningscommit, obligatorisk i TBD

Bästa praxis: hur man skriver en bra MR

En kvalitativ Merge Request (MR) förkortar granskningstiden och minskar antalet fel. Första regeln — en MR löser en uppgift. Om ändringar påverkar flera orelaterade funktioner bör de delas upp i separata MR. Andra — MR-titeln bör vara informativ: “Add OAuth2 authentication with Google provider” istället för “Fix stuff” eller “Update code”.

Enligt Google Engineering Practices, 2024 innehåller en bra MR en kontextbeskrivning: varför ändringarna är nödvändiga, hur de testades, vilka riskerna är. MR-storleken bör inte överstiga 400 rader ändringar. Om volymen är större — bör uppgiften delas upp i deluppgifter. För dokumentation och tester är undantag tillåtna, men med förklaring.

Merge Request (MR) bör innehålla automatiska tester för ny funktionalitet. I GitLab kan policyn Coverage Check konfigureras — MR blockeras automatiskt om kodtäckningen har sjunkit under tröskeln (t.ex. 80%). Detta garanterar att ny funktionalitet inte sänker projektets övergripande kvalitet.

• En MR — en uppgift: dela upp stora ändringar i flera små MR
• Beskrivning med mall: använd .gitlab/merge_request_templates för enhetlighet
• Storlek upp till 400 rader: stora MR granskas långsammare och med fler fel
• Tester obligatoriska: nya funktioner bör täckas av enhetstester

Mallar för MR-beskrivning

GitLab stöder Merge Request-mallar via filerna .gitlab/merge_request_templates/. Mallen innehåller sektioner: vad har gjorts, hur man testar, relaterade uppgifter och checklista. Användning av mallar påskyndar skapandet av MR och garanterar att utvecklare inte glömmer att ange viktig information. I MR-beskrivningen anges obligatoriskt relaterad issue (Closes #N) för automatisk stängning av uppgifter vid sammanslagning.