Cherry-pick — cos’è, meccanismo e applicazione in Git

Cos'è Cherry-pick?

Cherry-pick è un comando Git che copia le modifiche da un commit specificato e le applica come un nuovo commit nel ramo corrente. Il nome deriva dalla metafora “raccogliere ciliegie”: lo sviluppatore seleziona solo i commit di cui ha bisogno, ignorando il resto.

A differenza di Merge, cherry-pick non crea un commit di unione e non richiede l'unione completa dei rami. A differenza di Rebase, cherry-pick non trasferisce una sequenza di commit — solo quelli specificati. Questo rende cherry-pick uno strumento ideale per il trasferimento mirato di correzioni.

Secondo Atlassian, 2025, cherry-pick è utilizzato dal 47% dei team che lavorano con più rami di release contemporaneamente. Cherry-pick è particolarmente richiesto nello sviluppo mobile, dove vengono mantenute più versioni di un'applicazione (release LTS) contemporaneamente ed è necessario trasferire correzioni tra di esse.

Meccanismo di trasferimento

Durante l'esecuzione di cherry-pick, Git calcola il diff tra il commit specificato e il suo genitore, quindi applica questo diff al ramo corrente. Se le modifiche vengono applicate senza conflitti — Git crea un nuovo commit con lo stesso messaggio ma un nuovo SHA. Se c'è un conflitto — cherry-pick si ferma per la risoluzione manuale.

Come funziona Cherry-pick

La sintassi di cherry-pick è semplice: specifica l'hash del commit da trasferire. Git copia le modifiche nel ramo corrente come un nuovo commit. Il trasferimento di più commit contemporaneamente e di interi intervalli è supportato.

# Trasferire un singolo commit nel ramo corrente
git cherry-pick a1b2c3d4

# Trasferire più commit
git cherry-pick a1b2c3d4 e5f6g7h8

# Trasferire un intervallo di commit (da a1b2 a f9e8, escluso a1b2)
git cherry-pick a1b2c3d4..f9e8d7c6

Dopo l'esecuzione di cherry-pick, il ramo corrente riceve un nuovo commit con le modifiche dalla sorgente. Il messaggio del commit viene copiato dalla sorgente per impostazione predefinita, ma può essere modificato con il flag -n (non creare commit) o --edit (modificare il messaggio).

Esempio di trasferimento di una correzione

Consideriamo uno scenario tipico: un bug critico viene trovato e corretto in develop, che esiste anche nel ramo di release release/v2.0. Solo questa correzione deve essere trasferita, senza unire tutto develop nel ramo di release.

# Trovare l'hash del commit con la correzione in develop
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# Passare al ramo di release
git checkout release/v2.0

# Applicare la correzione
git cherry-pick a1b2c3d4

# In caso di conflitto — risolvere e continuare
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

Il flag -x aggiunge un riferimento allo SHA originale nel messaggio del commit: “(cherry picked from commit a1b2c3d4)”. Ciò facilita il tracciamento della provenienza del commit trasferito. Si raccomanda di usare -x in tutti gli scenari tranne le bozze temporanee.

Gestione dei conflitti

In caso di conflitto, cherry-pick si comporta come merge: Git si ferma e segna i file in conflitto. Lo sviluppatore risolve il conflitto, esegue git add e poi git cherry-pick --continue. Per annullare — git cherry-pick --abort. Il flag --strategy consente di specificare una strategia di unione (ad esempio, recursive con opzioni).

# Risoluzione di un conflitto durante cherry-pick
# Git mostra i file in conflitto
git status

# Risolvere manualmente, poi:
git add file_autorizzato.kt
git cherry-pick --continue

# Oppure annullare cherry-pick:
git cherry-pick --abort

Quando usare Cherry-pick

Cherry-pick è ottimale negli scenari in cui è necessario un trasferimento mirato di modifiche senza unire interi rami. Esaminiamo cinque casi principali in cui cherry-pick diventa la scelta migliore.

• Trasferimento hotfix — una correzione viene trovata in develop, ma deve essere applicata al ramo di release (release/v2.0). Cherry-pick trasferisce solo il commit della correzione senza influenzare le funzionalità non completate da develop
• Backport a versioni precedenti — una correzione per la versione corrente deve essere trasferita a una release LTS. Invece di unire l'intera base di codice corrente, cherry-pick seleziona solo i commit necessari
• Annullamento di un commit nel ramo sbagliato — se un commit è stato fatto nel ramo sbagliato, cherry-pick lo trasferisce in quello corretto e il commit originale viene annullato
• Trasferimento di documentazione — le modifiche a README o file di configurazione che devono essere presenti in tutti i rami sono comode da trasferire tramite cherry-pick
• Applicazione selettiva — da un ramo prototipo, solo un commit di successo deve essere preso senza trasferire l'intero prototipo nello sviluppo principale

Per lo sviluppo mobile, cherry-pick è fondamentale quando si supportano più versioni di un'applicazione. Ad esempio, se un bug viene trovato nella versione 3.2 già pubblicata su Google Play, e develop contiene codice per la versione 4.0 — cherry-pick consente di trasferire la correzione al ramo v3.x senza unire tutte le modifiche sostanziali. Ciò è particolarmente rilevante per i progetti in cui due o più versioni principali con API e dipendenze diverse vengono mantenute contemporaneamente.

Esempio pratico: in un'applicazione mobile viene rilevato un crash durante l'autenticazione tramite Google Sign-In su Android 12. La correzione viene effettuata in develop e supera la revisione del codice. Tuttavia, il ramo di release corrente v2.5 è già in fase di beta testing. Il cherry-pick del commit di correzione da develop a release/v2.5 consente di includere la correzione nella prossima release senza trasferire altre modifiche che non sono ancora pronte per la pubblicazione.

Quando si utilizza cherry-pick in progetti mobili, è importante considerare le dipendenze: se la correzione riguarda file che sono stati modificati in develop dopo il punto di divergenza del ramo di release, cherry-pick potrebbe portare un set incompleto di modifiche. In tali casi, è necessario verificare che tutte le modifiche correlate siano state anch'esse trasferite, altrimenti l'applicazione potrebbe non compilare o funzionare in modo errato. Controllare sempre la build dopo cherry-pick prima di inviare le modifiche al ramo condiviso.

Cherry-pick vs Merge vs Rebase

I tre strumenti principali per l'integrazione delle modifiche in Git — merge, rebase e cherry-pick — risolvono compiti diversi. La scelta dipende da quanto cambiamento deve essere trasferito e come deve apparire la cronologia.

Merge — quando è necessario unire due rami completamente e preservare le informazioni di ramificazione. Rebase — quando è necessario aggiornare un ramo personale allo stato più recente con una cronologia pulita. Cherry-pick — quando è necessario solo un commit o più commit selezionati.

In pratica, questi strumenti vengono combinati: una funzionalità viene sviluppata con rebase periodico su develop, poi unita tramite --no-ff merge, e quando è necessario trasferire una correzione a un altro ramo, viene utilizzato cherry-pick. Ogni strumento risolve il proprio compito nella propria fase.

Rischi e limitazioni di Cherry-pick

Cherry-pick è uno strumento utile ma potenzialmente pericoloso se usato in modo errato o eccessivo. I principali rischi sono legati alla duplicazione dei commit, alla perdita di contesto e ai conflitti durante le unioni successive.

• Duplicazione dei commit — se lo stesso commit successivamente entra nel ramo tramite merge, Git creerà un secondo commit identico nelle modifiche. Ciò inquina la cronologia e complica git bisect
• Perdita di contesto — cherry-pick trasferisce il diff ma non trasferisce informazioni sui commit genitori e le dipendenze. Se cherry-pick ha applicato il commit A senza il commit B da cui A dipendeva, possono verificarsi errori logici
• Conflitti di unione — dopo cherry-pick, durante un'unione completa di rami, Git potrebbe vedere le stesse modifiche due volte e creare conflitti che sarebbero stati evitati con un merge normale
• Mancanza di tracciabilità — senza il flag -x, è impossibile sapere che un commit è stato trasferito da un altro ramo. Cercando l'origine di una modifica, uno sviluppatore potrebbe passare ore a determinare la provenienza del commit

Raccomandazioni per minimizzare i rischi: utilizzare sempre il flag -x per indicare lo SHA originale, documentare il motivo del cherry-pick nel messaggio del commit e, quando possibile, utilizzare merge invece di cherry-pick quando il contesto lo consente. Se i cherry-pick diventano numerosi — prendere in considerazione una ristrutturazione dei rami.

Controlli automatizzati per Cherry-pick

Le pipeline CI dovrebbero considerare cherry-pick come uno scenario separato. Si raccomanda di configurare un controllo automatizzato: quando viene creato un commit cherry-pick, il CI verifica che i file modificati corrispondano al set previsto ed esegue test per i moduli interessati. Ciò riduce il rischio di regressione durante il trasferimento di modifiche tra rami.