Cherry-pick: co to je, jak se provádí cherry-pick a Git příkazy

Co je cherry-pick v Gitu

Cherry-pick — je příkaz git cherry-pick, který bere změny z existujícího commitu a aplikuje je jako nový commit v aktuální větvi. Původní commit zůstává na svém místě ve své větvi, zatímco v cílové větvi je vytvořena kopie změn. Příkaz je užitečný, když potřebujete přenést konkrétní opravu bez přemístění celé větve.

Syntaxe: git cherry-pick <commit-hash>. Git analyzuje rozdíl (diff) určeného commitu s jeho rodičem a aplikuje tento rozdíl na aktuální větev. Pokud se změny týkají několika souborů — všechny se přenášejí společně. Příkaz také přijímá rozsahy: git cherry-pick A..B — všechny commity od A do B, kromě A.

Příznaky rozšiřují možnosti: -n (--no-commit) aplikuje změny do pracovního adresáře a indexu bez vytvoření commitu — užitečné, když potřebujete sloučit změny více commitů do jednoho. Příznak -x přidá do zprávy commitu řádek (cherry picked from commit ...), což usnadňuje sledování původu změn v historii.

# Cherry-pick jednoho commitu podle hashe
git cherry-pick a1b2c3d

# Cherry-pick více commitů (postupně)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l

# Cherry-pick bez automatického commitu
git cherry-pick -n a1b2c3d

# Příznak -x přidá odkaz na původní commit
git cherry-pick -x a1b2c3d

Kdy se používá cherry-pick

Hlavní scénář — přenos oprav mezi vydanými větvemi. Představte si: v developu byla nalezena a opravena kritická chyba. Vydaná větev release/v2.1 je již oddělena a tato chyba je v ní také přítomna. Merge celého developu do release by přinesl mnoho nehotového kódu, zatímco cherry-pick jednoho commitu s opravou je bezpečné a přesné řešení.

Druhý scénář — zrušení změn (revert) s následným obnovením. Pokud byl commit zrušen pomocí git revert a později se ukázalo, že zrušení bylo chybné — cherry-pick zrušeného commitu obnoví změny. To je správnější než zrušení revertu, protože nevytváří opakované konflikty.

Třetí scénář — slučování commitů z různých feature větví do jedné testovací větve pro integrační testování. Místo slučování několika nedokončených větví (s nehotovým kódem) můžete vybrat pouze hotové commity z každé z nich a otestovat jejich spolupráci.

• Opravy chyb — přenos opravy z developu do release bez nehotového kódu.
• Hotfix — aplikace opravy z hotfix větve do main a developu zároveň.
• Zrušení chybného revertu — cherry-pick zrušeného commitu pro obnovení změn.
• Testování — sběr vybraných commitů z různých větví pro integrační kontrolu.

Cherry-pick vs rebase a merge

Cherry-pick se liší od rebase a merge tím, že pracuje na úrovni jednotlivých commitů, nikoli celých větví. Zatímco rebase přenáší všechny commity větve a merge slučuje dvě větve, cherry-pick vybírá pouze potřebné. To z něj dělá přesnější nástroj, ale také více ruční.

Další rozdíl — autorství. Při cherry-pick Git ve výchozím nastavení zachovává autora (Author) původního commitu, ale committer (Committer) se stává aktuální uživatel. Ve zprávě commitu lze původ vysledovat pomocí příznaku -x. Při rebase jsou autor i committer aktuální uživatel s novým hashem.

Výkon: cherry-pick jednoho commitu je rychlejší než merge dvou větví s mnoha commity. Ale pokud potřebujete přenést desítky commitů, je lepší vytvořit dočasnou větev a provést rebase — to je efektivnější a nevyžaduje uvádění desítek hashů.

Přenos více commitů

Více commitů lze přenést jedním příkazem, vyjmenováním jejich hashů oddělených mezerou: git cherry-pick A B C. Git aplikuje commity postupně v určeném pořadí. Pokud některý z commitů způsobí konflikt, cherry-pick se pozastaví a vývojář musí konflikt vyřešit, poté může pokračovat příkazem git cherry-pick --continue.

Rozsah commitů: git cherry-pick A..B (všechny commity po A do B, kromě A) a git cherry-pick A^..B (všechny commity od A včetně do B). Rozsahy jsou vhodné, když potřebujete přenést všechny commity z jedné větve bez rodičovského vztahu — například při přenosu hotové funkce ze staré větve do nové.

Příznak --strategy určuje, jak Git bude aplikovat změny. Ve výchozím nastavení se používá recursive strategie, ale lze zadat ours nebo theirs pro automatický výběr strany konfliktu. Příznak --mainline se používá při cherry-pick merge commitu — určuje číslo rodiče (1 nebo 2), vůči kterému se vypočítává diff.

# Cherry-pick rozsahu commitů
git cherry-pick develop~5..develop~2

# Cherry-pick merge commitu (určení rodiče)
git cherry-pick -m 1 m9n0o1p

# Použití theirs strategie
git cherry-pick --strategy=recursive \
  --strategy-option=theirs a1b2c3d

# Pokračovat po vyřešení konfliktu
git cherry-pick --continue

Konflikty při cherry-pick

Konflikty při cherry-pick vznikají, když se změny přenášeného commitu dotýkají stejných řádků, které byly změněny v cílové větvi. Git pozastaví provádění, označí konfliktní soubory a čeká na řešení. Ve stavu se tyto soubory zobrazují jako both modified.

Postup při konfliktu: otevřete konfliktní soubor, najděte značky konfliktu (<<<<<<<, =======, >>>>>>>), upravte obsah, odstraňte značky, proveďte git add pro vyřešené soubory a spustěte git cherry-pick --continue. Pokud je konflikt neřešitelný — git cherry-pick --abort zruší celý cherry-pick a vrátí větev do původního stavu.

Častý problém: commit již obsahuje změny odpovídající existujícím. V tomto případě Git hlásí «nothing to commit» nebo «empty commit» při pokusu o cherry-pick. Příznaky --keep-redundant-commits a --empty=keep nutí Git vytvořit prázdný commit pro zachování posloupnosti, zatímco --skip umožňuje takový commit přeskočit.

# Konflikt během cherry-pick — zastavit
git cherry-pick a1b2c3d
# error: could not apply a1b2c3d... commit message

# Vyřešit konflikt → přidat do indexu
git add src/conflicted_file.swift
git cherry-pick --continue

# Přeskočit prázdný commit (již aplikováno)
git cherry-pick --skip

# Úplné zrušení
git cherry-pick --abort

Nejlepší postupy cherry-pick

První pravidlo: vždy zkontrolujte, zda je přenášený commit samostatný. Pokud commit A závisí na změnách v commitu B, který se nepřenáší, cherry-pick A může zlomit sestavení. Před cherry-pick je užitečné zkontrolovat, jaké soubory commit změnil, pomocí git show --stat <hash>.

Druhé pravidlo: dokumentujte cherry-pick. Použijte příznak -x, aby zpráva commitu obsahovala odkaz na původní commit. To pomůže při následné analýze historie pochopit, odkud změna pochází. Bez -x vypadá cherry-pick jako běžný commit a jeho původ lze zjistit pouze pomocí git log --graph.

Třetí pravidlo: vyhněte se cherry-pick mezi větvemi, které se příliš rozcházejí. Pokud od vytvoření commitu uplynulo hodně času a kódová základna se výrazně změnila, konflikty budou četné a složité. V takových případech je lepší provést opravu znovu v cílové větvi — zabere to méně času než řešení desítek konfliktů.

• Cherry-pick pouze samostatné commity bez externích závislostí.
• Příznak -x je povinný pro dokumentaci původu commitu ve zprávě.
• Vyhněte se cherry-pick starých commitů s velkým rozchodem kódové základny.
• CI/CD zkontrolujte sestavení po cherry-pick: konflikt nemusí nastat, ale kód se nemusí zkompilovat.
• Komentář v PR při vytváření pull requestu uveďte, které commity byly přeneseny pomocí cherry-pick.