Cherry-pick — ce este, mecanismul și aplicarea în Git

Ce este Cherry-pick?

Cherry-pick — este o comandă Git care copiază modificări dintr-un commit specificat și le aplică ca un nou commit în ramura curentă. Numele provine de la metafora „a culege cireșe”: dezvoltatorul selectează doar commiturile de care are nevoie, ignorând restul.

Spre deosebire de Merge, cherry-pick nu creează un merge commit și nu necesită îmbinarea completă a ramurilor. Spre deosebire de Rebase, cherry-pick nu transferă o secvență de commituri — doar pe cele specificate. Acest lucru face din cherry-pick un instrument ideal pentru transferul precis al corecțiilor.

Potrivit datelor Atlassian, 2025, cherry-pick este utilizat în 47% dintre echipele care lucrează simultan cu mai multe ramuri de release. Cherry-pick este deosebit de solicitat în dezvoltarea mobilă, unde sunt suportate simultan mai multe versiuni ale aplicației (release-uri LTS) și este necesar transferul corecțiilor între ele.

Mecanismul de transfer

La executarea cherry-pick, Git calculează diff între commitul specificat și părintele său, apoi aplică acest diff ramurii curente. Dacă modificările s-au aplicat fără conflict — Git creează un nou commit cu același mesaj, dar cu un SHA nou. Dacă există un conflict — cherry-pick este suspendat pentru rezolvarea manuală.

Cum funcționează Cherry-pick

Sintaxa cherry-pick este simplă: specificați hash-ul commitului pe care doriți să-l transferați. Git va copia modificările în ramura curentă ca un nou commit. Este suportat transferul mai multor commituri simultan și al intervalelor întregi.

# Transferul unui commit în ramura curentă
git cherry-pick a1b2c3d4

# Transferul mai multor commituri
git cherry-pick a1b2c3d4 e5f6g7h8

# Transferul unui interval de commituri (de la a1b2 la f9e8, neincluzând a1b2)
git cherry-pick a1b2c3d4..f9e8d7c6

După executarea cherry-pick, ramura curentă primește un nou commit cu modificări din original. Mesajul commitului este copiat implicit din original, dar poate fi modificat cu flag-ul -n (nu crea commit) sau --edit (editează mesajul).

Exemplu de transfer al corecției

Să considerăm scenariul tipic: în develop a fost găsită și corectată o eroare critică, care este prezentă și în ramura de release release/v2.0. Trebuie transferată doar această corecție, fără a îmbina întregul develop în ramura de release.

# Găsiți hash-ul commitului cu corecția în develop
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# Comutați pe ramura de release
git checkout release/v2.0

# Aplicați corecția
git cherry-pick a1b2c3d4

# Dacă există conflict — rezolvați și continuați
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

Flag-ul -x adaugă în mesajul commitului o referință la SHA-ul original: „(cherry picked from commit a1b2c3d4)”. Acest lucru facilitează urmărirea de unde a fost transferat commitul. Se recomandă utilizarea -x în toate scenariile, cu excepția ciornelor temporare.

Lucrul cu conflicte

La conflict, cherry-pick se comportă ca merge: Git se oprește și marchează fișierele cu conflict. Dezvoltatorul rezolvă conflictul, execută git add și apoi git cherry-pick --continue. Pentru anulare — git cherry-pick --abort. Flag-ul --strategy permite specificarea strategiei de îmbinare (de exemplu, recursive cu opțiuni).

# Rezolvarea conflictului la cherry-pick
# Git arată fișierele cu conflict
git status

# Rezolvați manual, apoi:
git add razreshennyy_fayl.kt
git cherry-pick --continue

# Sau anulați cherry-pick:
git cherry-pick --abort

Când se aplică Cherry-pick

Cherry-pick este optim în scenarii unde este necesar transferul precis al modificărilor fără îmbinarea ramurilor întregi. Să analizăm cinci cazuri principale în care cherry-pick devine cea mai bună alegere.

• Transferul hotfix-ului — corecția a fost găsită în develop, dar trebuie aplicată în ramura de release (release/v2.0). Cherry-pick transferă doar commitul corecției, fără a afecta funcționalitățile neterminate din develop
• Backport în versiuni vechi — corecția pentru versiunea curentă trebuie transferată în release-ul LTS. În loc să îmbinați întreaga bază de cod curentă, cherry-pick selectează doar commiturile necesare
• Anularea commitului în altă ramură — dacă commitul a fost făcut în ramura greșită, cherry-pick îl transferă în ramura corectă, iar commitul original este anulat
• Transferul documentației — modificările în README sau fișierele de configurare care trebuie să fie în toate ramurile se transferă convenabil prin cherry-pick
• Aplicarea selectivă — din ramura de prototip trebuie luat doar un commit reușit, fără a transfera întregul prototip în dezvoltarea principală

Pentru dezvoltarea mobilă, cherry-pick este critic la suportul mai multor versiuni ale aplicației. De exemplu, dacă o eroare a fost găsită în versiunea 3.2 deja lansată în Google Play, iar develop conține cod pentru versiunea 4.0 — cherry-pick permite transferul corecției în ramura v3.x fără îmbinarea tuturor breaking changes. Acest lucru este deosebit de relevant pentru proiecte unde sunt suportate simultan două sau mai multe versiuni majore cu API-uri și dependențe diferite.

Exemplu din practică: într-o aplicație mobilă a fost descoperit un crash la autentificarea prin Google Sign-In pe Android 12. Corecția a fost introdusă în develop și a trecut de review. Însă ramura de release curentă v2.5 este deja în faza de testare beta. Cherry-pick al commitului corecției din develop în release/v2.5 permite includerea corecției în următorul release, fără a transfera restul modificărilor care nu sunt încă pregătite pentru lansare.

La utilizarea cherry-pick în proiecte mobile este important să se țină cont de dependențe: dacă corecția afectează fișiere care au fost modificate în develop după punctul de divergență al ramurii de release, cherry-pick poate aduce un set incomplet de modificări. În astfel de cazuri, trebuie verificat că toate modificările conexe au fost, de asemenea, transferate, altfel aplicația s-ar putea să nu se compileze sau să funcționeze incorect. Verificați întotdeauna compilarea după cherry-pick înainte de a trimite modificările în ramura comună.

Cherry-pick vs Merge vs Rebase

Trei instrumente principale de integrare a modificărilor în Git — merge, rebase și cherry-pick — rezolvă sarcini diferite. Alegerea depinde de ce volum de modificări trebuie transferat și cum ar trebui să arate istoricul.

Merge — când trebuie îmbinate două ramuri în întregime și păstrată informația despre ramificare. Rebase — când trebuie actualizată o ramură personală la starea curentă cu un istoric curat. Cherry-pick — când este necesar doar un commit sau câteva commituri selectate.

În practică, aceste instrumente sunt combinate: funcționalitatea este dezvoltată cu rebase periodic pe develop, apoi îmbinată prin --no-ff merge, iar la necesitatea transferării corecției în altă ramură se folosește cherry-pick. Fiecare instrument își rezolvă sarcina în etapa sa.

Riscuri și limitări Cherry-pick

Cherry-pick — un instrument util, dar potențial periculos la utilizarea incorectă sau excesivă. Riscurile principale sunt legate de duplicarea commiturilor, pierderea contextului și conflictele la îmbinările ulterioare.

• Duplicarea commiturilor — dacă același commit ajunge ulterior în ramură prin merge, Git va crea un al doilea commit, identic ca modificări. Acest lucru poluează istoricul și îngreunează git bisect
• Pierderea contextului — cherry-pick transferă diff-ul, dar nu transferă informația despre commiturile părinte și dependențe. Dacă cherry-pick a aplicat commitul A fără commitul B de care A depindea, pot apărea erori logice
• Conflicte la merge — după cherry-pick, la îmbinarea completă a ramurilor, Git poate vedea aceleași modificări de două ori și crea conflicte care puteau fi evitate la un merge obișnuit
• Lipsa legăturii — fără flag-ul -x nu se poate înțelege că commitul a fost transferat din altă ramură. La căutarea originii modificării, dezvoltatorul poate petrece ore întregi pentru a determina proveniența commitului

Recomandări pentru minimizarea riscurilor: utilizați întotdeauna flag-ul -x pentru a indica SHA-ul original, documentați motivul cherry-pick în mesajul commitului și, pe cât posibil, utilizați merge în loc de cherry-pick când contextul permite. Dacă cherry-pick-urile devin prea multe — luați în considerare restructurarea ramurilor.

Automatizarea verificărilor la Cherry-pick

Pipeline-urile CI trebuie să ia în considerare cherry-pick ca un scenariu separat. Se recomandă configurarea unei verificări automate: la crearea unui commit cherry-pick, CI verifică dacă fișierele modificate corespund setului așteptat și lansează teste pentru modulele afectate. Acest lucru reduce riscul de regresie la transferul precis al modificărilor între ramuri.