Cherry-pick — co to je, mechanismus a použití v Gitu

Co je Cherry-pick?

Cherry-pick — je příkaz Git, který kopíruje změny z určeného commitu a aplikuje je jako nový commit v aktuální větvi. Název pochází z metafory „vybírat třešně“: vývojář vybírá pouze ty commity, které potřebuje, a ignoruje ostatní.

Na rozdíl od Merge, cherry-pick nevytváří merge commit a nevyžaduje úplné sloučení větví. Na rozdíl od Rebase, cherry-pick nepřenáší sekvenci commitů — pouze určené. To činí cherry-pick ideálním nástrojem pro přesný přenos oprav.

Podle údajů Atlassian, 2025 se cherry-pick používá ve 47 % týmů, které pracují současně s několika release větvemi. Cherry-pick je obzvláště žádaný v mobilním vývoji, kde je současně podporováno několik verzí aplikace (LTS releasy) a je vyžadován přenos oprav mezi nimi.

Mechanismus přenosu

Při provádění cherry-pick Git vypočítá diff mezi určeným commitem a jeho rodičem, poté aplikuje tento diff na aktuální větev. Pokud se změny aplikovaly bez konfliktu — Git vytvoří nový commit se stejnou zprávou, ale novým SHA. Pokud dojde ke konfliktu — cherry-pick se pozastaví pro ruční řešení.

Jak Cherry-pick funguje

Syntaxe cherry-pick je jednoduchá: zadejte hash commitu, který chcete přenést. Git zkopíruje změny do aktuální větve jako nový commit. Podporován je přenos několika commitů najednou a celých rozsahů.

# Přenos jednoho commitu do aktuální větve
git cherry-pick a1b2c3d4

# Přenos několika commitů
git cherry-pick a1b2c3d4 e5f6g7h8

# Přenos rozsahu commitů (od a1b2 do f9e8, bez a1b2)
git cherry-pick a1b2c3d4..f9e8d7c6

Po provedení cherry-pick získá aktuální větev nový commit se změnami z originálu. Zpráva commitu se standardně kopíruje z originálu, ale lze ji změnit pomocí příznaku -n (nevytvářet commit) nebo --edit (upravit zprávu).

Příklad přenosu opravy

Zvažme typický scénář: v develop byla nalezena a opravena kritická chyba, která je také přítomna v release větvi release/v2.0. Je třeba přenést pouze tuto opravu, aniž by se sloučil celý develop do release větve.

# Najděte hash commitu s opravou v develop
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# Přepněte se na release větev
git checkout release/v2.0

# Aplikujte opravu
git cherry-pick a1b2c3d4

# Pokud je konflikt — vyřešte a pokračujte
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

Příznak -x přidá do zprávy commitu odkaz na původní SHA: „(cherry picked from commit a1b2c3d4)“. To usnadňuje sledování, odkud byl commit přenesen. Doporučuje se používat -x ve všech scénářích kromě dočasných konceptů.

Práce s konflikty

Při konfliktu se cherry-pick chová jako merge: Git se zastaví a označí konfliktní soubory. Vývojář konflikt vyřeší, provede git add a poté git cherry-pick --continue. Pro zrušení — git cherry-pick --abort. Příznak --strategy umožňuje určit strategii sloučení (např. recursive s možnostmi).

# Řešení konfliktu při cherry-pick
# Git zobrazuje konfliktní soubory
git status

# Vyřešte ručně, poté:
git add povolený_soubor.kt
git cherry-pick --continue

# Nebo zrušte cherry-pick:
git cherry-pick --abort

Kdy použít Cherry-pick

Cherry-pick je optimální ve scénářích, kde je vyžadován přesný přenos změn bez sloučení celých větví. Podívejme se na pět hlavních případů, kdy se cherry-pick stává nejlepší volbou.

• Přenos hotfixu — oprava byla nalezena v develop, ale musí být aplikována v release větvi (release/v2.0). Cherry-pick přenáší pouze commit opravy, aniž by se dotýkal nedokončených funkcí z develop
• Backport do starých verzí — oprava pro aktuální verzi musí být přenesena do LTS releasu. Místo sloučení celé aktuální kódové základny cherry-pick vybírá pouze potřebné commity
• Zrušení commitu v jiné větvi — pokud byl commit proveden ve špatné větvi, cherry-pick jej přenese do správné větve a původní commit se zruší
• Přenos dokumentace — změny v README nebo konfiguračních souborech, které by měly být ve všech větvích, lze pohodlně přenášet přes cherry-pick
• Selektivní aplikace — z prototype větve je třeba vzít pouze jeden úspěšný commit, aniž by se celý prototype přenášel do hlavního vývoje

Pro mobilní vývoj je cherry-pick kriticky důležitý při podpoře několika verzí aplikace. Například, pokud je chyba nalezena ve verzi 3.2 již vydané v Google Play, zatímco develop obsahuje kód pro verzi 4.0 — cherry-pick umožňuje přenést opravu do větve v3.x bez sloučení všech breaking changes. To je obzvláště důležité pro projekty, kde jsou současně podporovány dvě nebo více hlavních verzí s různými API a závislostmi.

Příklad z praxe: v mobilní aplikaci byl objeven crash při autorizaci přes Google Sign-In na Android 12. Oprava byla zanesena do develop a prošla revizí. Aktuální release větev v2.5 je však již ve fázi beta testování. Cherry-pick commitu opravy z develop do release/v2.5 umožňuje zahrnout opravu do příštího releasu, aniž by se přenášely ostatní změny, které ještě nejsou připraveny k vydání.

Při použití cherry-pick v mobilních projektech je důležité zohlednit závislosti: pokud oprava ovlivňuje soubory, které byly změněny v develop po bodu divergence release větve, cherry-pick může přinést neúplnou sadu změn. V takových případech je třeba zkontrolovat, zda byly přeneseny také všechny související změny, jinak se aplikace nemusí zkompilovat nebo pracovat nesprávně. Vždy zkontrolujte sestavení po cherry-pick před tím, než změny pushnete do sdílené větve.

Cherry-pick vs Merge vs Rebase

Tři hlavní nástroje integrace změn v Gitu — merge, rebase a cherry-pick — řeší různé úkoly. Výběr závisí na tom, jaký objem změn je třeba přenést a jak by měla vypadat historie.

Merge — když je třeba sloučit dvě větve v celku a zachovat informaci o větvení. Rebase — když je třeba aktualizovat osobní větev na aktuální stav s čistou historií. Cherry-pick — když je potřeba pouze jeden commit nebo několik vybraných commitů.

V praxi se tyto nástroje kombinují: funkce je vyvíjena s periodickým rebase na develop, poté sloučena přes --no-ff merge, a když je třeba přenést opravu do jiné větve, použije se cherry-pick. Každý nástroj řeší svůj úkol ve své fázi.

Rizika a omezení Cherry-pick

Cherry-pick — užitečný, ale potenciálně nebezpečný nástroj při nesprávném nebo nadměrném používání. Hlavní rizika souvisejí s duplikováním commitů, ztrátou kontextu a konflikty při pozdějších sloučeních.

• Duplikování commitů — pokud stejný commit později přijde do větve přes merge, Git vytvoří druhý commit, identický změnami. To znečišťuje historii a ztěžuje git bisect
• Ztráta kontextu — cherry-pick přenáší diff, ale nepřenáší informace o rodičovských commitech a závislostech. Pokud cherry-pick aplikoval commit A bez commitu B, na kterém A závisel, mohou vzniknout logické chyby
• Konflikty při merge — po cherry-pick při úplném sloučení větví může Git vidět stejné změny dvakrát a vytvořit konflikty, kterým bylo možné předejít při běžném merge
• Nedostatek spojení — bez příznaku -x nelze pochopit, že commit byl přenesen z jiné větve. Při hledání původu změny může vývojář strávit hodiny zjišťováním původu commitu

Doporučení pro minimalizaci rizik: vždy používejte příznak -x pro uvedení původního SHA, dokumentujte důvod cherry-pick ve zprávě commitu a pokud možno používejte merge místo cherry-pick, když to kontext dovoluje. Pokud je cherry-picků příliš mnoho — zvažte restrukturalizaci větví.

Automatizace kontrol při Cherry-pick

CI pipeline by měly brát cherry-pick v úvahu jako samostatný scénář. Doporučuje se nastavit automatickou kontrolu: při vytváření cherry-pick commitu CI zkontroluje, že změněné soubory odpovídají očekávané sadě, a spustí testy pro dotčené moduly. To snižuje riziko regrese při přesném přenosu změn mezi větvemi.