Cherry-pick: mi ez, hogyan történik a cherry-pick és Git-parancsok

Mi az a cherry-pick a Git-ben

Cherry-pick — a git cherry-pick parancs, amely egy létező commit változtatásait veszi és új commitként alkalmazza az aktuális ágon. Az eredeti commit a saját ágán marad, míg a célágban a változtatások másolata jön létre. A parancs akkor hasznos, ha egy adott javítást kell átvinni a teljes ág áthelyezése nélkül.

Szintaxis: git cherry-pick <commit-hash>. A Git elemzi a megadott commit és annak szülője közötti különbséget (diff), és ezt a különbséget alkalmazza az aktuális ágra. Ha a változtatások több fájlt érintenek — mindegyik együtt kerül átvitelre. A parancs tartományokat is elfogad: git cherry-pick A..B — az összes commit A-tól B-ig, A nélkül.

A flag-ek bővítik a lehetőségeket: a -n (--no-commit) a munka könyvtárba és indexbe alkalmazza a változtatásokat commit létrehozása nélkül — hasznos, ha több commit változtatásait kell egyesíteni egyetlen commitba. A -x flag hozzáad egy (cherry picked from commit ...) sort a commit üzenethez, ami megkönnyíti a változtatások eredetének nyomon követését a történetben.

# Egy commit cherry-pick-elése hash alapján
git cherry-pick a1b2c3d

# Több commit cherry-pick-elése (egymás után)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l

# Cherry-pick automatikus commit nélkül
git cherry-pick -n a1b2c3d

# -x flag hivatkozást ad az eredeti commitra
git cherry-pick -x a1b2c3d

Mikor használjuk a cherry-pick-ot

Fő forgatókönyv — javítások átvitele kiadási ágak között. Képzelje el: a develop-ban találtak és kijavítottak egy kritikus hibát. A release/v2.1 kiadási ág már el van különítve, és ez a hiba is jelen van benne. A teljes develop merge-elése a release-be sok befejezetlen kódot hozna át, míg egyetlen javító commit cherry-pick-elése biztonságos és pontos megoldás.

Második forgatókönyv — változtatások visszavonása (revert) utáni helyreállítás. Ha egy commitot git revert-tel visszavontak, és utóbb kiderül, hogy a visszavonás téves volt — a visszavont commit cherry-pick-elése helyreállítja a változtatásokat. Ez helyesebb, mint a revert visszavonása, mert nem okoz ismétlődő konfliktusokat.

Harmadik forgatókönyv — commitok összegyűjtése különböző feature-ágakból egyetlen tesztágba integrációs teszteléshez. Több befejezetlen ág (befejezetlen kóddal) összeolvasztása helyett kiválaszthatja csak a kész commitokat mindegyikből, és tesztelheti azok együttműködését.

• Hibajavítások — javítás átvitele develop-ból release-be befejezetlen kód nélkül.
• Hotfix — javítás alkalmazása hotfix-ágból main-be és develop-be egyszerre.
• Téves revert visszavonása — a visszavont commit cherry-pick-elése a változtatások helyreállításához.
• Tesztelés — kiválasztott commitok gyűjtése különböző ágakból integrációs ellenőrzéshez.

Cherry-pick vs rebase és merge

Cherry-pick abban különbözik a rebase-től és merge-től, hogy egyedi commitok szintjén dolgozik, nem pedig teljes ágakkal. Míg a rebase átviszi az ág összes commitját, a merge pedig két ágat egyesít, addig a cherry-pick csak a szükségeseket választja ki. Ez pontosabb eszközzé teszi, de több kézi munkát igényel.

Másik különbség — szerzőség. Cherry-pick-nél a Git alapértelmezésben megtartja az eredeti commit szerzőjét (Author), de a committer (Committer) az aktuális felhasználó lesz. A commit üzenetben az eredet a -x flag segítségével követhető nyomon. Rebase-nél a szerző és a committer egyaránt az aktuális felhasználó új hash-szel.

Teljesítmény: egyetlen commit cherry-pick-elése gyorsabb, mint két sok committal rendelkező ág merge-elése. De ha tucatnyi commitot kell átvinni, jobb ideiglenes ágat létrehozni és rebase-t végezni — ez hatékonyabb, és nem igényli tucatnyi hash megadását.

Több commit átvitele

Több commit átvihető egyetlen paranccsal, a hashek szóközzel történő felsorolásával: git cherry-pick A B C. A Git a commitokat a megadott sorrendben, egymás után alkalmazza. Ha valamelyik commit konfliktust okoz, a cherry-pick megszakad, és a fejlesztőnek fel kell oldania a konfliktust, majd a git cherry-pick --continue paranccsal folytathatja.

Commit tartomány: git cherry-pick A..B (az összes commit A után B-ig, A nélkül) és git cherry-pick A^..B (az összes commit A-tól kezdve B-ig). A tartományok akkor kényelmesek, ha egy ág összes commitját át kell vinni szülői kapcsolat nélkül — például egy kész funkció átvitelénél egy régi ágról egy újra.

A --strategy flag meghatározza, hogy a Git hogyan alkalmazza a változtatásokat. Alapértelmezésben a recursive stratégia használatos, de megadható ours vagy theirs a konfliktus oldalának automatikus kiválasztásához. A --mainline flag a merge-commit cherry-pick-elésénél használatos — megadja a szülő számát (1 vagy 2), amelyhez képest a diff számítódik.

# Commit tartomány cherry-pick-elése
git cherry-pick develop~5..develop~2

# Merge-commit cherry-pick-elése (szülő megadása)
git cherry-pick -m 1 m9n0o1p

# Theirs stratégia használata
git cherry-pick --strategy=recursive \
  --strategy-option=theirs a1b2c3d

# Folytatás konfliktus megoldása után
git cherry-pick --continue

Konfliktusok cherry-pick-nél

Konfliktusok cherry-pick-nél akkor keletkeznek, amikor az átvitt commit változtatásai ugyanazokat a sorokat érintik, amelyeket a célágban módosítottak. A Git felfüggeszti a végrehajtást, megjelöli az ütköző fájlokat, és vár a megoldásra. Az állapotban az ilyen fájlok both modified-ként jelennek meg.

Eljárás konfliktus esetén: nyissa meg az ütköző fájlt, keresse meg a konfliktusjelölőket (<<<<<<<, =======, >>>>>>>), szerkessze a tartalmat, távolítsa el a jelölőket, végezze el a git add parancsot a megoldott fájlokra, és indítsa el a git cherry-pick --continue parancsot. Ha a konfliktus nem oldható fel — a git cherry-pick --abort megszakítja a teljes cherry-pick-et, visszaállítva az ágat az eredeti állapotba.

Gyakori probléma: a commit már tartalmaz a meglévőkkel egyenértékű változtatásokat. Ebben az esetben a Git «nothing to commit» vagy «empty commit» üzenetet ad a cherry-pick próbálkozásnál. A --keep-redundant-commits és --empty=keep flag-ek arra kényszerítik a Git-et, hogy üres commitot hozzon lére a sorrend megőrzéséhez, míg a --skip lehetővé teszi az ilyen commit átugrását.

# Konfliktus cherry-pick közben — megállítás
git cherry-pick a1b2c3d
# error: could not apply a1b2c3d... commit message

# Konfliktus megoldása → hozzáadás az indexhez
git add src/conflicted_file.swift
git cherry-pick --continue

# Üred commit átugrása (már alkalmazva)
git cherry-pick --skip

# Teljes megszakítás
git cherry-pick --abort

Cherry-pick legjobb gyakorlatai

Első szabály: mindig ellenőrizze, hogy az átvitt commit önellátó-e. Ha az A commit függ a B commit változtatásaitól, amely nem kerül átvitelre, az A cherry-pick-elése összetörheti a build-et. Cherry-pick előtt érdemes ellenőrizni, hogy a commit milyen fájlokat módosított a git show --stat <hash> segítségével.

Második szabály: dokumentálja a cherry-pick-ot. Használja a -x flag-et, hogy a commit üzenet tartalmazza a hivatkozást az eredeti commitra. Ez segít a későbbi történetelemzésnél megérteni, honnan származik a változtatás. -x nélkül a cherry-pick egy szokványos commitnak tűnik, és az eredete csak a git log --graph segítségével állapítható meg.

Harmadik szabály: kerülje a cherry-pick-ot olyan ágak között, amelyek túl nagy távolságra vannak egymástól. Ha a commit létrehozása óta sok idő telt el, és a kódbázis jelentősen megváltozott, a konfliktusok számosak és összetettek lesznek. Ilyen esetekben jobb a javítást újra elkészíteni a célágban — ez kevesebb időt vesz igénybe, mint tucatnyi konfliktus feloldása.

• Cherry-pick csak önellátó commitokat külső függőségek nélkül.
• -x flag kötelező a commit eredetének dokumentálásához az üzenetben.
• Kerülje a régi commitok cherry-pick-elését, ahol a kódbázis nagy eltérést mutat.
• CI/CD ellenőrizze a build-et cherry-pick után: előfordulhat, hogy nincs konfliktus, de a kód nem fordul le.
• Megjegyzés a PR-ben pull request létrehozásakor tüntesse fel, mely commitok kerültek átvitelre cherry-pick segítségével.