Cherry-pick — mi ez, mechanizmusa és alkalmazása Git-ben

Mi az a Cherry-pick?

Cherry-pick — egy Git parancs, amely lemásolja a megadott commit módosításait, és új commitként alkalmazza az aktuális ágban. A név a “cseresznyét szedni” metaforából származik: a fejlesztő csak a szükséges commiteket választja ki, a többit figyelmen kívül hagyja.

Ellentétben a Merge-tel, a cherry-pick nem hoz létre merge commitot, és nem igényli az ágak teljes egyesítését. Ellentétben a Rebase-szel, a cherry-pick nem visz át commitsorozatot — csak a megadottakat. Ez teszi a cherry-pick-et ideális eszközzé a célzott javításátvitelhez.

A Atlassian, 2025 adatai szerint a cherry-pick-et a csapatok 47%-a használja, akik egyszerre több kiadási ággal dolgoznak. A cherry-pick különösen keresett a mobilfejlesztésben, ahol egyszerre több alkalmazásverzió (LTS kiadások) támogatott, és szükség van a javítások ágak közötti átvitelére.

Az átvitel mechanizmusa

A cherry-pick végrehajtásakor a Git kiszámítja a diff-et a megadott commit és szülője között, majd ezt a diff-et alkalmazza az aktuális ágra. Ha a módosítások konfliktus nélkül alkalmazódtak — a Git létrehoz egy új commitet ugyanazzal az üzenettel, de új SHA-val. Ha konfliktus van — a cherry-pick felfüggesztésre kerül kézi megoldásra.

Hogyan működik a Cherry-pick

A cherry-pick szintaxisa egyszerű: adja meg az átvinni kívánt commit hash-ét. A Git lemásolja a módosításokat az aktuális ágba új commitként. Több commit egyidejű átvitele és teljes tartományok is támogatottak.

# Egy commit átvitele az aktuális ágba
git cherry-pick a1b2c3d4

# Több commit átvitele
git cherry-pick a1b2c3d4 e5f6g7h8

# Commit-tartomány átvitele (a1b2-től f9e8-ig, a1b2 nélkül)
git cherry-pick a1b2c3d4..f9e8d7c6

A cherry-pick végrehajtása után az aktuális ág kap egy új commitet az eredeti módosításaival. A commit üzenet alapértelmezetten az eredetiből másolódik, de módosítható a -n (ne hozzon létre commitet) vagy a --edit (üzenet szerkesztése) kapcsolóval.

Példa javítás átvitelére

Tekintsünk egy tipikus forgatókönyvet: a develop-ban találtak és kijavítottak egy kritikus hibát, amely a release/v2.0 kiadási ágban is jelen van. Csak ezt a javítást kell átvinni anélkül, hogy a teljes develop-ot egyesítenénk a kiadási ágba.

# Keresse meg a javítást tartalmazó commit hash-ét a develop-ban
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# Váltson a kiadási ágra
git checkout release/v2.0

# Alkalmazza a javítást
git cherry-pick a1b2c3d4

# Ha konfliktus van — oldja meg és folytassa
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

A -x kapcsoló hivatkozást ad az eredeti SHA-ra a commit üzenetben: “(cherry picked from commit a1b2c3d4)”. Ez megkönnyíti annak nyomon követését, hogy honnan került át a commit. A -x használata minden forgatókönyvben ajánlott, kivéve az ideiglenes vázlatokat.

Konfliktusok kezelése

Konfliktus esetén a cherry-pick úgy viselkedik, mint a merge: a Git megáll és megjelöli a konfliktusos fájlokat. A fejlesztő megoldja a konfliktust, végrehajtja a git add-et, majd a git cherry-pick --continue-t. Megszakításhoz — git cherry-pick --abort. A --strategy kapcsoló lehetővé teszi az egyesítési stratégia megadását (pl. recursive opciókkal).

# Konfliktus megoldása cherry-pick-nél
# A Git megjeleníti a konfliktusos fájlokat
git status

# Oldja meg kézzel, majd:
git add razreshennyj_fajl.kt
git cherry-pick --continue

# Vagy szakítsa meg a cherry-pick-et:
git cherry-pick --abort

Mikor alkalmazzuk a Cherry-pick-et

Cherry-pick optimális olyan forgatókönyvekben, ahol a módosítások célzott átvitele szükséges teljes ágak egyesítése nélkül. Vizsgáljuk meg azt az öt fő esetet, amikor a cherry-pick a legjobb választás.

• Hotfix átvitele — a javítást a develop-ban találták, de a kiadási ágban (release/v2.0) kell alkalmazni. A cherry-pick csak a javítás commitját viszi át anélkül, hogy hozzányúlna a befejezetlen funkciókhoz a develop-ból
• Backport régebbi verziókba — a jelenlegi verzió javítását át kell vinni az LTS kiadásba. Ahelyett, hogy a teljes aktuális kódbázist egyesítenék, a cherry-pick csak a szükséges commiteket választja ki
• Commit visszavonása másik ágban — ha a commit rossz ágban készült, a cherry-pick átviszi a megfelelő ágba, az eredeti commit pedig visszavonásra kerül
• Dokumentáció átvitele — a README vagy konfigurációs fájlok módosításai, amelyeknek minden ágban szerepelniük kell, kényelmesen átvihetők cherry-pick-kel
• Szelektív alkalmazás — a prototípus ágból csak egy sikeres commitet kell kivenni, anélkül hogy a teljes prototípust átvinnék a fő fejlesztésbe

A mobilfejlesztés számára a cherry-pick kritikus fontosságú több alkalmazásverzió támogatásakor. Például, ha egy hibát a Google Play-ben már kiadott 3.2 verzióban találnak, míg a develop a 4.0 verzió kódját tartalmazza — a cherry-pick lehetővé teszi a javítás átvitelét a v3.x ágba az összes breaking changes egyesítése nélkül. Ez különösen fontos olyan projekteknél, ahol egyszerre két vagy több főverziót támogatnak eltérő API-kkal és függőségekkel.

Gyakorlati példa: egy mobilalkalmazásban crash-t fedeztek fel a Google Sign-In-en keresztüli hitelesítés során Android 12-n. A javítást bevezették a develop-ba, és átment a review-n. Az aktuális kiadási ág, a v2.5 azonban már béta tesztelési fázisban van. A javítás commitjának cherry-pick-je a develop-ból a release/v2.5-be lehetővé teszi a javítás beépítését a következő kiadásba anélkül, hogy átvinnék a többi, még kiadásra nem kész módosítást.

A cherry-pick mobil projektekben való használatakor fontos figyelembe venni a függőségeket: ha a javítás olyan fájlokat érint, amelyeket a develop-ban módosítottak a kiadási ág elágazási pontja után, a cherry-pick hiányos módosításkészletet hozhat. Ilyen esetekben ellenőrizni kell, hogy az összes kapcsolódó módosítás is átvitelre került-e, különben az alkalmazás nem fordulhat le, vagy hibásan működhet. Mindig ellenőrizze a build-et cherry-pick után, mielűtt a módosításokat a közös ágba push-olná.

Cherry-pick vs Merge vs Rebase

A Git-ben a módosítások integrálásának három fő eszköze — a merge, a rebase és a cherry-pick — különböző feladatokat old meg. A választás attól függ, hogy mennyi módosítást kell átvinni, és hogyan nézzen ki a történet.

Merge — amikor két ágat teljesen egyesíteni kell, és meg kell őrizni az elágazás információit. Rebase — amikor egy személyes ágat kell frissíteni az aktuális állapotra tiszta történettel. Cherry-pick — amikor csak egy vagy néhány kiválasztott commit szükséges.

A gyakorlatban ezek az eszközök kombinálódnak: a funkció fejlesztése időszakos rebase-szel történik a develop-ra, majd --no-ff merge segítségével egyesítik, és amikor egy javítást át kell vinni egy másik ágba, cherry-pick-et használnak. Minden eszköz a saját szakaszában oldja meg a feladatát.

A Cherry-pick kockázatai és korlátai

Cherry-pick — hasznos, de potenciálisan veszélyes eszköz helytelen vagy túlzott használat esetén. A fő kockázatok a commitek duplikálásával, a kontextus elvesztésével és a későbbi egyesítéseknél fellépő konfliktusokkal kapcsolatosak.

• Commitek duplikálása — ha ugyanaz a commit később merge-en keresztül kerül az ágba, a Git létrehoz egy második, módosításaiban azonos commitet. Ez szennyezi a történetet és megnehezíti a git bisect-et
• Kontextus elvesztése — a cherry-pick átviszi a diff-et, de nem viszi át a szülő commitekre és függőségekre vonatkozó információkat. Ha a cherry-pick alkalmazta az A commitet a B commit nélkül, amelytől A függött, logikai hibák léphetnek fel
• Konfliktusok merge-nél — cherry-pick után, az ágak teljes egyesítésekor a Git kétszer láthatja ugyanazokat a módosításokat, és olyan konfliktusokat hozhat létre, amelyek normál merge esetén elkerülhetők lettek volna
• Kapcsolat hiánya — a -x kapcsoló nélkül lehetetlen megérteni, hogy a commit egy másik ágból került át. A módosítás eredetének keresésekor a fejlesztő órákat tölthet a commit származásának megállapításával

Javaslatok a kockázatok minimalizálására: mindig használja a -x kapcsolót az eredeti SHA megadásához, dokumentálja a cherry-pick okát a commit üzenetben, és lehetőség szerint használjon merge-t cherry-pick helyett, ha a kontextus engedi. Ha túl sok a cherry-pick — fontolja meg az ágak átszervezését.

Ellenőrzések automatizálása Cherry-pick esetén

CI pipeline-oknak külön forgatókönyvként kell kezelniük a cherry-pick-et. Javasolt automatikus ellenőrzés beállítása: a cherry-pick commit létrehozásakor a CI ellenőrzi, hogy a módosított fájlok megfelelnek-e a várt készletnek, és teszteket futtat az érintett modulokra. Ez csökkenti a regresszió kockázatát a módosítások ágak közötti célzott átvitelekor.