Merge Request (MR): co to je, jak vytvořit a proces revize

Co je Merge Request (MR)?

Merge Request (MR) — žádost o integraci změn z jedné větve Git do druhé, která zahajuje proces code review a automatické kontroly. Na rozdíl od přímého sloučení přes konzoli vytváří MR formální postup: vývojář popíše změny, přiřadí recenzenty, spustí CI/CD a obdrží zpětnou vazbu před aplikací změn. Je to klíčový prvek GitLab, ale analogický mechanismus v GitHub se nazývá Pull Request (PR).

Podle GitLab Documentation, 2026 se v GitLab vytvoří ročně více než 80 milionů Merge Request. Každý MR obsahuje čtyři hlavní komponenty: popis (description) s kontextem změn, seznam commitů (commits), rozdíl v kódu (diff) a diskusi (discussion thread). Bez jednoho z těchto prvků je MR považován za neúplný.

Merge Request (MR) řeší tři úkoly: zabraňuje přímým změnám v chráněných větvích (main, develop), zajišťuje kontrolu kvality prostřednictvím revize a uchovává historii diskusí pro budoucí vývojáře. V GitLab se stav MR zobrazuje v rozhraní s barevnou indikací: šedá pro Draft, oranžová pro čekání, zelená pro Approved, fialová pro Merged a červená pro Closed.

Terminologie: MR, PR a CR

Na různých Git platformách se Merge Request nazývá odlišně. GitLab používá „Merge Request” (MR), GitHub — „Pull Request” (PR). Analogie — Change Request (CR) v Gerrit. Všechny tři označují stejný proces: žádost o integraci změn prostřednictvím code review. Výběr termínu závisí pouze na platformě používané v projektu.

# Vytvořit větev se změnami
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# MR lze vytvořit přes UI GitLab/GitHub nebo CLI:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR vs PR: jaký je rozdíl mezi GitLab a GitHub

Merge Request v GitLab a Pull Request v GitHub — jsou funkčně identické mechanismy s různými názvy. Rozdíl je historický: GitLab se původně postavil jako Self-Hosted alternativa k GitHub a zvolil termín „Merge Request” pro proces sloučení. GitHub, spuštěný dříve, použil „Pull Request” — žádost o „pull” (stažení) změn do hlavní větve.

Podle GitHub Docs, 2024 oba nástroje podporují stejnou sadu funkcí: popis s Markdown, přiřazení recenzentů, komentování konkrétních řádků kódu, stavy kontrol a automatické sloučení při splnění podmínek. Rozdíly se týkají rozhraní a dalších možností.

Jak vytvořit Merge Request: návod krok za krokem

Vytvoření Merge Request (MR) začíná publikováním větve se změnami ve vzdáleném repozitáři. Po push do GitLab nebo GitHub se v rozhraní objeví tlačítko „Create Merge Request” nebo „Compare & Pull Request”. Vývojář vyplní popis, uvede cílovou větev (obvykle develop nebo main), přiřadí recenzenty a přidá štítky (labels).

Podle GitLab Documentation, 2025 obsahuje standardní MR název do 72 znaků, popis se šablonou (template) a odkaz na úkol (issue). Popis by měl odpovídat na otázky: co bylo provedeno, proč, jak bylo testováno. GitLab podporuje automatické uzavírání issue při sloučení pomocí klíčových slov Closes, Fixes, Resolves.

# Příklad šablony .gitlab/merge_request_templates/default.md
## What does this MR do?

[Stručný popis změn: co a proč]

## How to test

1. Spustit ./gradlew test
2. Ověřit LoginActivity s testovacím tokenem
3. Ověřit, že nedošlo k regresi v AuthManager

## Related issues

Closes #142

Životní cyklus MR: od Draft po Merged

Merge Request (MR) prochází pěti stavy v GitLab. První — Draft (koncept), označený předponou „Draft:” v názvu a blokující sloučení. Po připravení vývojář odstraní Draft a MR přejde do stavu Opened — začíná code review a spouští se CI/CD pipeline.

Podle GitLab Docs, 2024 ve stavu Opened recenzenti prohlížejí diff, zanechávají komentáře a požadují změny prostřednictvím Resolve Threads. Když jsou všechna vlákna uzavřena a CI/CD úspěšně projde, odpovědný vývojář nastaví Approve. Poté lze MR sloučit tlačítkem Merge nebo počkat na automatické sloučení (Auto-merge).

GitLab podporuje tři varianty konečného stavu: Merged (úspěšně sloučeno), Closed (uzavřeno bez sloučení, např. při zrušení funkce) a Reopened (znovu otevřeno po uzavření). Každý stav je zaznamenán v Activity Timeline MR pro audit.

Automatické stavy a spouštěče

GitLab automaticky aktualizuje stav Merge Request při událostech: při push nových commitů se Approvals resetují, při úspěšném CI pipeline se stav změní na Pipeline passed, při chybě — Pipeline failed (sloučení je blokováno). Lze nakonfigurovat Auto-merge: MR se automaticky sloučí po úspěšném CI a získání všech požadovaných schválení.

• Draft — koncept, CI se spouští, ale sloučení je blokováno
• Opened — připraveno k revizi, přiřazeni recenzenti, pipeline aktivní
• Approved — získán požadovaný počet schválení
• Merged — změny sloučeny do cílové větve
• Closed — uzavřeno bez sloučení

Pravidla code review v Merge Request

Code review v Merge Request (MR) — povinná fáze ve většině komerčních projektů. Podle výzkumu SmartBear, 2023, code review s MR snižuje počet defektů o 30–60% a urychluje zaučení nových vývojářů. Hlavní pravidlo — každý MR kontroluje alespoň jeden, lépe dva vývojáři, kteří se nepodíleli na psaní kódu.

Kontrola MR zahrnuje pět kritérií: správnost logiky, dodržování stylu kódu, pokrytí testy, bezpečnost a výkon. V GitLab lze nakonfigurovat Required Approvals — povinný počet schválení před sloučením, např. 2 schválení pro main a 1 pro develop.

Diskuse v MR probíhá v Threads — komentářích ke konkrétním řádkům kódu. Každé vlákno musí být resolved (uzavřeno) před sloučením. Pro urychlení revize se doporučuje omezit velikost MR: 200–400 řádků změn. Podle Google Research (2022) jsou MR o objemu více než 400 řádků kontrolovány o 30% méně efektivně.

CI/CD pipeline v Merge Request

Při vytvoření Merge Request (MR) se automaticky spouští CI/CD pipeline. V GitLab k tomu dochází prostřednictvím souboru .gitlab-ci.yml, v GitHub — prostřednictvím GitHub Actions workflow. Pipeline zahrnuje sestavení projektu (build), spuštění unit testů (unit tests), lintery (lint), statickou analýzu (SAST) a kontrolu pokrytí kódu.

Podle GitLab Blog, 2024 se stav pipeline zobrazuje přímo v MR: zelené zatržítko (passed), červený křížek (failed) nebo žlutý kruh (running). Pokud pipeline selže, GitLab blokuje tlačítko Merge do opravy. V nastavení lze zapnout „Merge when pipeline succeeds” — automatické sloučení po úspěšné pipeline.

# .gitlab-ci.yml — příklad pro Android projekt
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

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

Metody sloučení: Squash, Merge Commit, Fast-Forward

GitLab a GitHub nabízejí tři metody sloučení pro Merge Request. Volba závisí na politice týmu a požadované čistotě historie. Merge Commit — vytváří samostatný commit sloučení, zachovávající celou historii feature větve. Squash — sloučí všechny commity větve do jednoho commitu na cílové větvi. Fast-Forward — aplikuje commity lineárně bez commitu sloučení.

Podle GitLab Docs, 2025 je Squash preferován v projektech s vysokou hustotou commitů (20+ commitů v jedné feature větvi). Fast-Forward je povinný pro Trunk-Based Development. Merge Commit se používá v Git Flow pro zachování sémantiky větvení.

• Merge Commit — zachovává historii, vytváří commit sloučení, vhodný pro Git Flow
• Squash — slučuje všechny commity do jednoho, čistá historie, mezilehlé commity se ztrácejí
• Fast-Forward — lineární historie bez commitu sloučení, povinný v TBD

Nejlepší postupy: jak napsat dobrý MR

Kvalitní Merge Request (MR) zkracuje dobu revize a snižuje počet chyb. První pravidlo — jeden MR řeší jeden úkol. Pokud změny ovlivňují několik nesouvisejících funkcí, měly by být rozděleny do samostatných MR. Druhé — název MR by měl být informativní: „Add OAuth2 authentication with Google provider” místo „Fix stuff” nebo „Update code”.

Podle Google Engineering Practices, 2024 dobrý MR obsahuje popis kontextu: proč jsou změny nutné, jak byly testovány, jaká jsou rizika. Velikost MR by neměla přesáhnout 400 řádků změn. Pokud je objem větší — úkol by měl být rozložen na podúkoly. Pro dokumentaci a testy jsou výjimky povoleny, ale s vysvětlením.

Merge Request (MR) by měl obsahovat automatické testy nové funkcionality. V GitLab lze nakonfigurovat politiku Coverage Check — MR se automaticky blokuje, pokud pokrytí kódu kleslo pod práh (např. 80%). To zaručuje, že nová funkcionalita nesnižuje celkovou kvalitu projektu.

• Jeden MR — jeden úkol: rozdělte velké změny na několik malých MR
• Popis se šablonou: používejte .gitlab/merge_request_templates pro jednotnost
• Velikost do 400 řádků: velké MR jsou kontrolovány pomaleji a s více chybami
• Testy povinné: nové funkce by měly být pokryty unit testy

Šablony popisu MR

GitLab podporuje šablony Merge Request prostřednictvím souborů .gitlab/merge_request_templates/. Šablona obsahuje sekce: co bylo provedeno, jak testovat, související úkoly a kontrolní seznam. Používání šablon urychluje vytváření MR a zaručuje, že vývojáři nezapomenou uvést důležité informace. V popisu MR se povinně uvádí související issue (Closes #N) pro automatické uzavírání úkolů při sloučení.