Merge — co to je, typy slučování a mechanismus fungování

Co je Merge?

Merge (sloučení) — je základní operace v Gitu, která spojuje změny z jedné větve (source) do druhé (target). Výsledkem sloučení je, že cílová větev obdrží všechny commity ze zdrojové větve, které v ní ještě nebyly. V závislosti na situaci může Git provést merge třemi různými způsoby.

Hlavní hodnotou merge je zachování historie: merge commit zaznamenává fakt sloučení větví, ukládá informaci o tom, kdy a které větve byly sloučeny. To usnadňuje audit změn, hledání regresí a pochopení chronologie vývoje. Ve velkých projektech je merge commit standardním způsobem integrace kódu.

Podle údajů GitLab Flow se merge commity používají v 73 % týmů pracujících s Gitem. Alternativní přístupy (rebase, squash) preferují týmy orientované na lineární historii. Volba strategie závisí na velikosti týmu, frekvenci vydání a přijatých dohodách v projektu.

Kdy nastává Merge

Merge je potřebný, když vývojář dokončil práci na funkci a chce ji integrovat do develop nebo main. Typický scénář: vývojář vytvořil větev funkce z develop, pracoval na ní několik dní a během té doby se v develop objevily nové commity od ostatních účastníků. Před sloučením je třeba změny spojit — a k tomu slouží merge.

Bez merge není možné společně pracovat na jednom kódu v Gitu. Pokaždé, když dva vývojáři současně provádějí změny ve stejné kódové základně, jejich větve se rozcházejí. Merge — je jediný způsob, jak tyto změny znovu spojit bez ztráty dat.

Typy slučování v Gitu

Git podporuje tři typy merge, každý určený pro svůj scénář. Volba typu sloučení ovlivňuje historii commitů, pohodlí vracení a čitelnost logu.

Fast-forward merge

Fast-forward nastává, když cílová větev neměla od vytvoření zdrojové větve žádné nové commity. V tomto případě Git jednoduše posune ukazatel cílové větve vpřed na poslední commit zdrojové větve. Historie zůstává lineární, bez merge commitu.

# Fast-forward merge: develop se nezměnil od vytvoření feature
git checkout develop
git merge feature/new-login

# Výsledek: ukazatel develop se přesunul na konec feature
# Nebyl vytvořen žádný merge commit

Fast-forward je vhodný pro krátkodobé větve, kde vývojář pracoval sám. Tento přístup má však nevýhodu: ztrácí se informace o tom, že větev existovala — všechny commity vypadají jako provedené přímo v develop.

Three-way merge

Three-way merge se provádí, když obě větve mají nové commity po bodu divergence. Git vytvoří samostatný merge commit se dvěma rodiči, který zaznamenává fakt sloučení větví. Tento přístup se doporučuje pro větve funkcí v týmovém vývoji.

# Vynucený three-way merge s příznakem --no-ff
git checkout develop
git merge --no-ff feature/new-login

# Vytvořen merge commit s výchozí zprávou
# Vlastní zprávu lze nastavit pomocí -m
git merge --no-ff feature/new-login -m "Merge feature/new-login into develop"

Příznak --no-ff zaručuje vytvoření merge commitu, i když je fast-forward možný. To je nejlepší praxe pro zachování informací o větvení v projektu.

Squash merge

Squash merge stlačí všechny commity zdrojové větve do jednoho a aplikuje je na cílovou větev. Historie funkce se ztrácí — do větve přijde jeden commit se všemi změnami. To je vhodné, když podrobné commity ve větvi funkce nenesou hodnotu pro celkovou historii.

# Squash merge: všechny commity feature stlačeny do jednoho
git checkout develop
git merge --squash feature/experimental
git commit -m "feat: experimental login flow (squashed)"

Squash je vhodný pro koncepty, experimentální větve a situace, kdy je důležité udržet čistotu historie. Nevýhoda — ztrácí se spojení s původními commity, což komplikuje vracení jednotlivých změn.

Strategie Ours a Theirs

Ours a Theirs — dvě speciální strategie merge v Gitu. Ours zcela ignoruje změny ze zdrojové větve a ponechává pouze to, co je v cílové větvi. Theirs naopak při každém konfliktu přijímá verzi zdrojové větve. Tyto strategie jsou užitečné při slučování velkých objemů kódu, když je předem známo, která verze má zvítězit.

Jak Merge funguje

Mechanismus merge v Gitu je založen na porovnání tří bodů: společného předka (merge base), stavu zdrojové větve a stavu cílové větve. Git najde merge base — poslední commit společný pro obě větve — a vypočítá, jaké změny nastaly v každé větvi po divergenci.

• Krok 1 — Git určí merge base: poslední commit, který existuje v obou větvích
• Krok 2 — Git vytvoří dva diffy: od merge base k source a od merge base k target
• Krok 3 — Git se pokusí aplikovat obě sady změn na merge base
• Krok 4 — Pokud změny nekolidují — merge se automaticky dokončí
• Krok 5 — Pokud dojde ke konfliktu — Git se zastaví a požádá o řešení

Git používá třícestný algoritmus slučování, který bere v úvahu nejen dvě porovnávané verze souboru, ale také jejich společného předka. Díky tomu může Git automaticky řešit situace, kdy změny v jedné větvi neovlivňují změněné části druhé — i když byly oba soubory změněny.

Algoritmus fungování merge na příkladu

Uvažujme scénář: dva vývojáři pracují na různých souborech ve stejné větvi funkce. První změnil LoginActivity.kt, druhý — ProfileFragment.kt. Když spojí své změny, Git vidí, že změny se týkají různých souborů, a provede merge automaticky, bez lidského zásahu.

Pokud oba vývojáři změnili LoginActivity.kt, ale v různých metodách — Git si také poradí automaticky a spojí změny řádek po řádku. Konflikt vzniká pouze tehdy, když oba změnili stejné řádky nebo když jeden smazal kód, který druhý změnil.

Řešení konfliktů při Merge

Konflikt merge vzniká, když Git nemůže automaticky spojit změny, protože obě větve změnily stejné řádky různým způsobem. V tomto případě Git označí konfliktní místa v souborech a očekává ruční řešení od vývojáře.

Konfliktní místa jsou označena speciálními značkami: <<<<<<< HEAD zobrazuje kód z cílové větve, ======= — oddělovač, >>>>>>> source-branch — kód ze zdrojové větve. Vývojář musí ručně vybrat, kterou variantu ponechat, nebo je spojit.

# 1. Spustit merge a vidět konflikt
git merge feature/new-login
# Výstup: CONFLICT (content): Merge conflict in LoginActivity.kt

# 2. Zobrazit seznam souborů s konflikty
git status
# both modified: src/ui/login/LoginActivity.kt

# 3. Vyřešit konflikt: upravit soubor, odstranit značky
# 4. Přidat vyřešený soubor a dokončit merge
git add src/ui/login/LoginActivity.kt
git merge --continue
# nebo: git commit (bez --continue)

Pro řešení konfliktů existují nástroje: git mergetool otevře vizuální nástroj pro slučování (Meld, Beyond Compare, VS Code). Mnoho vývojářů dává přednost řešení konfliktů v IDE — IntelliJ IDEA a Android Studio poskytují vestavěný nástroj s třípanelovým porovnáním, který tento proces výrazně zjednodušuje.

Tipy pro řešení konfliktů: vždy rozumějte tomu, co dělá každá strana konfliktu, neodstraňujte cizí kód bez pochopení jeho logiky, a pokud je konflikt příliš složitý — zapojte autora obou větví do společného řešení.

Merge vs Rebase: kdy co zvolit

Volba mezi Merge a Rebase — jedno z nejčastějších architektonických rozhodnutí v Gitu. Oba přístupy spojují změny, ale dělají to odlišně: merge zachovává historii větvení, rebase přepisuje historii a činí ji lineární.

• Merge — zachovává kontext: je vidět, kdy a ze které větve bylo sloučení provedeno. Lepší pro veřejné větve (develop, main) a týmovou práci
• Rebase — vytváří čistou lineární historii bez zbytečných merge commitů. Lepší pro osobní větve funkcí před odesláním k recenzi
• Pravidlo: nikdy nedělejte rebase na veřejných větvích, které používají jiní vývojáři

Mnoho týmů používá hybridní přístup: rebase pro uvedení větve funkce do aktuálního stavu develop (git rebase develop), poté merge s příznakem --no-ff pro zaznamenání sloučení. To poskytuje čistou historii uvnitř funkce a informativní body sloučení na úrovni develop.