Rebase: co to je, jak funguje a práce s Git

Co je rebase v Gitu

Rebase — je příkaz Gitu, který přenastaví aktuální větev na zadanou větev: vezme všechny commity aktuální větve, dočasně je uloží, přesune ukazatel větve na cílový commit a postupně aplikuje uložené commity na jeho vrchol. Výsledek — historie vypadá, jako by vývojář pracoval přímo od posledního commitu cílové větve.

Základní syntaxe: git rebase main — při pobytu ve feature větvi tento příkaz přesune všechny feature commity na vrchol main. Git používá strategii three-way merge pro každý commit zvlášť. Pokud je commit A již přítomen v cílové větvi (určeno podle hashe), Git ho automaticky přeskočí, čímž se vyhne duplikování změn.

Rebase také podporuje onto režim pro přesun části commitů: git rebase --onto target start end — tato forma umožňuje extrahovat rozsah commitů z jedné větve a aplikovat je na vrchol jiné. Například git rebase --onto main feature~3 feature přesune poslední tři commity feature větve na vrchol main.

# Přepni na feature větev
git checkout feature

# Přenastav feature na main
git rebase main

# Po úspěšném rebase — historie je lineární
git log --oneline --graph

# Přesun poslední 3 commity do main
git rebase --onto main HEAD~3 HEAD

Rebase vs Merge: klíčové rozdíly

Rebase a merge řeší stejný úkol — spojení změn z různých větví — ale dělají to zásadně odlišnými způsoby. Merge zachovává kompletní historii sloučení vytvořením merge-commitu se dvěma rodiči. Rebase přepisuje historii a činí ji lineární. Volba mezi nimi závisí na workflow týmu a pravidlech práce s repozitářem.

Hlavní rozdíl — jak je zaznamenán fakt sloučení. Merge uchovává: „v tomto bodě jsme sloučili feature do main” — to je informativní pro historii projektu, ale při častých sloučeních zaneřádí log. Rebase ukazuje: „feature commity byly provedeny postupně od posledního stavu main” — to je čisté, ale skrývá fakt, že práce probíhala paralelně.

Druhý rozdíl — zpracování konfliktů. Při merge se konflikty řeší jednou a řešení je zaznamenáno v merge-commitu. Při rebase mohou konflikty vzniknout pro každý přesouvaný commit a každý vyžaduje samostatné řešení. Je to pracnější, ale umožňuje přesnější kontrolu nad tím, které změny se dostanou do konečné verze.

Interaktivní rebase: příkazy a přepínače

Interaktivní rebase (git rebase -i) — je režim, ve kterém Git otevře editor se seznamem commitů a dostupnými akcemi pro každý z nich. Vývojář může přepsat historii před odesláním do vzdáleného repozitáře. To je hlavní nástroj pro udržování čistoty commitů ve feature větvi.

Dostupné příkazy v interaktivním režimu: pick (ponechej commit tak, jak je), reword (změň zprávu commitu), edit (zastav se pro změny), squash (spoj s předchozím commitem, ponechej obě zprávy), fixup (spoj, zahoď zprávu), drop (odstraň commit). Každý příkaz se uvádí před hash commitu v otevřeném editoru.

Squash a fixup — nejčastěji používané příkazy pro spojování commitů. Pokud vývojář provedl 5 malých commitů s opravami během práce, squash je spojí do jednoho logického commitu se smysluplnou zprávou. Fixup je užitečný pro opravu překlepů: změny se dostanou do předchozího commitu bez uložení vlastní zprávy.

# Otevři editor pro poslední 4 commity
git rebase -i HEAD~4

# Editor zobrazí:
pick a1b2c3d Add authentication
pick e4f5g6h Fix typo in login
squash i6j7k8l Additional login fixes
pick m9n0o1p Add auth tests

# Po uložení — Git provede rebase
# a otevře editor pro sloučenou zprávu commitu

# Auto-squash bez otevření editoru
git rebase -i HEAD~4 --autosquash

Přepínač --autosquash automaticky nastaví fixup/squash pro commity, jejichž zprávy začínají fixup! nebo squash!. Urychluje práci, pokud vývojář předem označí commity pro pozdější spojení. Přepínač --committer-date-is-author-date zachovává původní datum commitu při rebase — užitečné pro zachování chronologie v historii.

Řešení konfliktů při rebase

Konflikty při rebase vznikají, když Git nemůže automaticky aplikovat přesouvaný commit kvůli rozporům se změnami v cílové větvi. Na rozdíl od merge, kde se konflikt řeší jednou, při rebase může každý commit způsobit konflikt a musí se řešit postupně pro každý commit od nejstaršího po nejnovější.

Když konflikt nastane, Git pozastaví rebase a oznámí, který commit způsobil problém. Vývojář otevře konfliktní soubor (Git označí konfliktní oblasti značkami <<<<<<<, =======, >>>>>>>), upraví ho, přidá do indexu (git add) a pokračuje v rebase příkazem git rebase --continue. Pokud není nalezeno řešení — git rebase --abort zcela zruší rebase.

Tip: při vícenásobných konfliktech je efektivnější použít git mergetool, který otevře vizuální editor pro řešení rozporů. Lze také přeskočit problematický commit (git rebase --skip), ale to odstraní jeho změny z konečné historie, což je málokdy správným řešením.

# Zahájit rebase s konfliktem
git rebase main
# Auto-merging file.txt
# KONFLIKT (obsah): Konflikt sloučení v file.txt

# Zkontrolovat stav
git status
# oba změněny: file.txt

# Uprav konfliktní sekce → git add → pokračuj
git add file.txt
git rebase --continue

# V případě pochyb — zruš
git rebase --abort

Kdy nelze rebase provádět

Zlaté pravidlo rebase: nikdy nepřesouvejte commity, které již byly odeslány do vzdáleného repozitáře a jsou dostupné jiným vývojářům. Protože rebase přepisuje hashe commitů, kolegové narazí na konflikty při pokusu o synchronizaci — jejich lokální historie bude v rozporu s přepsanou vzdálenou.

Situace, ve které je rebase kategoricky zakázán: pokud již někdo vytvořil větev na základě vašich commitů (například váš kolega vytvořil feature z vašeho feature), změna historie zničí jeho práci. V takových případech je třeba použít merge. Také se nedoporučuje provádět rebase těsně před termínem — chyba při řešení konfliktů může trvat déle, než se očekávalo, a zablokovat vydání.

Výjimka: pokud větev používá pouze jeden vývojář (osobní feature větev, nezveřejněná nebo zveřejněná v draft režimu), rebase před pushem je standardní praxí. Po zveřejnění a zahájení týmové práce — pouze merge. GitHub a GitLab ve výchozím nastavení nabízejí squash merge jako kompromis: spojí commity do jednoho, ale nepřepisuje historii cílové větve.

• Veřejné větve (main, develop, release) — rebase zcela zakázán.
• Cizí commity — pokud větev obsahuje commity jiného vývojáře, rebase je nepřípustný.
• Před vydáním — riziko konfliktů je vyšší: merge je bezpečnější den před termínem.
• Větve se značkami — přesun commitu se značkou porušuje konvence sémantického verzování.
• CI/CD vázané na hashe — některé systémy nasazení identifikují buildy podle hashe commitu; rebase rozbije sledování.

Praktický workflow s rebase

V moderních týmech se nejčastěji používá workflow orientovaný na rebase v kombinaci s GitHub Flow. Proces vypadá takto: vývojář vytvoří feature větev z main, pracuje v ní, periodicky synchronizuje pomocí git rebase main a před vytvořením pull requestu provede interaktivní rebase pro vyčištění historie.

Po vytvoření PR (pokud je potřeba stáhnout nové změny z main) se používá git pull --rebase main namísto běžného git pull. To umožňuje stáhnout změny bez vytvoření zbytečného merge-commitu. Git pull s přepínačem --rebase je ekvivalentní git fetch + git rebase — Git nejprve načte nové commity, poté přesune lokální změny na jejich vrchol.

Git umožňuje nastavit rebase jako výchozí chování pro pull: git config --global pull.rebase true. Po této konfiguraci git pull vždy provádí rebase místo merge. Pokud je potřeba běžný pull — použije se git pull --no-rebase. Mnoho týmů také zapíná autostash: git config --global rebase.autoStash true — to automaticky schová nepotvrzené změny před rebase a po něm je obnoví.