Rebase: co to je, čím se liší od Merge a princip fungování

Co je Rebase?

Rebase (rebazování) — je operace Git, která přesouvá commity z aktuální větve na nový referenční bod (základ). Místo vytvoření merge commitu rebase vezme každý commit ze zdrojové větve a postupně jej aplikuje na nový základ. Výsledkem je lineární sekvence commitů bez větvení.

Název rebase pochází z „re-base" — změnit základ. Zatímco merge spojuje dvě větve v jednom bodě, rebase ve skutečnosti přesouvá celou vaši větev na nové místo a vytváří iluzi, že jste začali vývoj z aktuálního stavu cílové větve. To vytváří dojem dokonale sekvenční práce.

Podle Atlassian, 2025 tráví týmy používající rebase pro feature větve o 30% méně času analýzou historie commitů ve srovnání s týmy používajícími výhradně merge. Lineární historie zjednodušuje git blame, bisect a prohlížení logu přes git log --oneline.

Zásadní rozdíl od Merge

Merge spojuje větve vytvořením commitu se dvěma rodiči. Rebase přepisuje historii: nové commity jsou vytvářeny znovu s novými hashi, i když změny v nich jsou identické s původními. To znamená, že rebase mění SHA identifikátory commitů, což je kritické pro veřejné větve.

Jak Rebase funguje

Mechanismus rebase se skládá ze čtyř kroků: Git určí společného předka (merge base) aktuální a cílové větve, poté postupně aplikuje každý commit aktuální větve na cílovou větev. Pokud v nějakém kroku nastane konflikt — rebase se zastaví a čeká na řešení.

# Počáteční situace: feature je o 3 commity pozadu za developem
git checkout feature/new-login
git rebase develop

# Git vezme 3 commity z feature a aplikuje je na develop
# Pokud nejsou konflikty — rebase se dokončí automaticky
# Pokud jsou — Git se zastaví na konfliktním commitu

Po rebase obsahuje feature větev všechny commity z developu plus své vlastní commity, které vypadají jako pokračování developu. To umožňuje sloučení do developu pomocí fast-forward, bez vytvoření merge commitu.

Postup krok za krokem

Podívejme se na podrobný příklad: vývojář vytvořil feature větev z developu, provedl dva commity, a mezitím jiní vývojáři přidali tři commity do developu. Rebase přesune dva commity feature na nové místo a vytvoří jejich kopie s novými SHA.

# 1. Vytvořit feature větev
git checkout -b feature/payment-refactor develop

# 2. Provést commity ve feature
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. Aktualizovat develop (práce kolegů)
git checkout develop
git pull

# 4. Rebazovat feature na nový develop
git checkout feature/payment-refactor
git rebase develop

# 5. Nyní lze feature sloučit pomocí fast-forward
git checkout develop
git merge feature/payment-refactor

Pokud v kroku 4 nastane konflikt, Git se zastaví na problematickém commitu. Vývojář konflikt vyřeší, provede git add a spustí git rebase --continue. Pokud je třeba commit přeskočit — git rebase --skip, pokud zrušit celý rebase — git rebase --abort.

Automatické přeskočení prázdných commitů

Příznak --empty řídí chování rebase při prázdných commitech — situacích, kdy jsou všechny změny commitu již přítomny v cílové větvi. Ve výchozím nastavení se rebase zastaví a požádá o rozhodnutí. S příznakem --empty=drop Git automaticky přeskočí takové commity bez zastavení, což urychluje hromadné rebazování s velkým počtem commitů.

Interaktivní Rebase

Interactive rebase (git rebase -i) — výkonný nástroj pro úpravu historie commitů. Otevře editor se seznamem commitů a klíčovými příkazy: pick (ponechat), reword (změnit zprávu), edit (změnit obsah), squash (sloučit s předchozím), fixup (sloučit bez zprávy), drop (smazat).

# Interaktivní rebase posledních 4 commitů
git rebase -i HEAD~4

# V editoru se otevře plán rebase:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# Měníme na:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

Výsledek: tři commity (přihlašovací obrazovka, validace, rozvržení) jsou sloučeny do jednoho a commit s komentáři je smazán. To umožňuje předložit čistou historii bez konceptů a oprav pro code review. Interactive rebase je standardní nástroj pro přípravu feature větve před Pull Requestem.

Rebase vs Merge: srovnání

Rebase a Merge řeší stejný úkol — integraci změn — ale zásadně odlišnými způsoby. Volba mezi nimi závisí na tom, jakou historii chcete vidět v git log a kdo další pracuje s vaší větví.

Praktické pravidlo: používejte merge pro integraci do společných větví (develop, main) a rebase pro aktualizaci osobních feature větví na aktuální stav. Mnoho týmů kombinuje: rebase feature na develop, poté --no-ff merge do developu.

Vliv na git bisect

Git bisect — nástroj pro nalezení commitu, který zavedl regresi. Při použití merge prochází git bisect správně merge commity s ohledem na oba rodiče. Při rebase pracuje bisect rychleji, protože historie je lineární a nevyžaduje větvení. Pokud však byl rebase proveden poté, co se commity staly známými týmu, původní SHA se ztratí a bisect nemusí problémový commit najít.

Kdy použít Rebase

Rebase je optimální ve třech scénářích: příprava feature větve na Pull Request, aktualizace osobní větve na aktuální stav main/develop a čištění historie před sloučením. V každém případě rebase zlepšuje čitelnost historie bez rizika pro týmovou práci.

Před Pull Requestem se doporučuje provést interactive rebase pro sloučení pracovních commitů (WIP, opravy po review) do smysluplných logických celků. To usnadňuje code review: recenzent nevidí 15 malých commitů, ale 3-5 strukturovaných změn se srozumitelnými zprávami.

Pro aktualizaci feature větve je rebase preferován před merge, protože nevytváří zbytečné merge commity. Pokud pravidelně děláte git rebase develop ve feature větvi, po konečném sloučení nebude kaskáda 10 merge commitů — pouze čisté commity funkce nad developem.

Čištění historie pomocí interactive rebase před sloučením umožňuje skrýt drobné opravy (překlepy, formátování) a seskupit commity podle funkčnosti. Git zprávy by měly dodržovat konvenci Conventional Commits (fix:, feat:, refactor:, docs:), která generuje automatický changelog.

Rizika a pravidla Rebase

Rebase — nebezpečná operace, pokud je aplikována nesprávně. Hlavní riziko — přepisování publikované historie. Pokud vývojář provede rebase větve, kterou ostatní již pushnuli a používají, jejich lokální kopie se desynchronizují a budou muset provést force-pull s rizikem ztráty dat.

• Zlaté pravidlo: nikdy nedělejte rebase commitů, které již existují ve sdíleném repozitáři. To se týká všech větví, ke kterým mají přístup ostatní členové týmu
• Force push: po rebase lokální feature větve je vyžadován push s příznakem --force-with-lease, který je bezpečnější než --force, protože kontroluje, zda někdo neaktualizoval větev na serveru
• Ztráta kontextu: rebase ničí informaci o tom, kdy a z které větve byla feature větev vytvořena. Pokud je důležité zachovat datum vytvoření větve — použijte merge
• Konflikty: při rebase je třeba konflikty řešit pro každý commit zvlášť, což může být při velkém počtu commitů zdlouhavé

Pro minimalizaci rizik dodržujte pravidlo: rebase pouze pro osobní větve, které nebyly publikovány. Pokud je větev již ve sdíleném repozitáři — použijte merge s --no-ff. Při potřebě rebase publikované větve — varujte tým a předem koordinujte force push.

Automatická ochrana před nebezpečným rebasem je realizována pomocí server-side hooks: pre-receive hook na straně Git serveru může kontrolovat, zda push nepřepisuje publikované commity. GitHub a GitLab poskytují vestavěnou ochranu pro chráněné větve — force push je blokován, pokud ochranu neodstraní administrátor.