git cherry-pick applica un commit specifico da un ramo a un altro — copiando solo i cambiamenti di quel commit, senza mergiare l'intero ramo. È utile per applicare selettivamente particolari cambiamenti, come il backporting di una correzione.
# apply a specific commit from another branch onto the current branch
git cherry-pick <commit-hash>
git cherry-pick <commit1> <commit2>
git cherry-pick A..B
Cherry-pick prende i cambiamenti da un commit specifico e li applica come un nuovo commit sul tuo ramo corrente — selettivamente, senza portare con sé il resto del ramo sorgente.
✓ BACKPORTING a fix — apply a bug fix from main to a release/maintenance branch
(without merging all of main's other changes into the release branch)
✓ Applying a specific commit that's ready, while the rest of its branch isn't
✓ Moving a commit made on the wrong branch to the correct one
✓ Selectively pulling one change from another branch
⚠️ Creates DUPLICATE commits (same changes, different hashes on each branch):
→ can cause confusion/conflicts if branches are later merged (the change appears twice,
though Git often handles it). Prefer merge/rebase for integrating whole branches.
⚠️ Cherry-picking many commits is a sign you might want a merge/rebase instead
⚠️ Conflicts can occur (resolve like a merge); use it deliberately, not as a default
→ Use cherry-pick for SELECTIVE, specific needs — not routine integration.
Capire git cherry-pick è prezioso per applicare selettivamente cambiamenti specifici, una capacità utile per situazioni particolari, quindi è una conoscenza pratica di Git che vale la pena acquisire.
La capacità fondamentale — applicare solo i cambiamenti di uno specifico commit su un altro ramo senza mergiare l'intero ramo — affronta esigenze reali che il merge non può gestire completamente.
L'uso più comune e importante è il backporting: applicare una specifica correzione di bug dal ramo principale a un ramo di rilascio o manutenzione, ottenendo solo quella correzione senza mergiare tutti gli altri cambiamenti (possibilmente instabili o non ancora rilasciati) del ramo principale nel ramo di rilascio — un'esigenza frequente nel mantenimento del software rilasciato.
Altri usi includono l'applicazione di un singolo commit pronto mentre il resto del suo ramo non lo è, lo spostamento di un commit fatto sul ramo sbagliato a quello giusto, e il pull selettivo di una modifica.
Capire le avvertenze è importante per usare cherry-pick appropriatamente: crea commit duplicati (gli stessi cambiamenti con hash diversi su ogni ramo), il che può causare confusione o conflitti se i rami vengono successivamente mergiati, quindi dovrebbe essere usato deliberatamente per esigenze selettive piuttosto che come metodo di integrazione routinario (merge o rebase sono migliori per integrare interi rami), e fare cherry-pick di molti commit è un segnale che probabilmente vuoi un merge invece.
Questo giudizio — usare cherry-pick per situazioni specifiche e selettive (specialmente backporting) preferendo merge/rebase per l'integrazione routinaria — riflette una pratica Git corretta.
Poiché applicare selettivamente cambiamenti specifici (specialmente il backporting di correzioni ai rami di rilascio) è un'esigenza reale, occasionalmente importante, e poiché cherry-pick è lo strumento per farlo (con avvertenze sul suo uso appropriato), capire git cherry-pick — come funziona, i suoi principali casi d'uso come il backporting, e quando usarlo rispetto a merge/rebase — è una conoscenza Git preziente e praticamente rilevante per gestire gli scenari di cambiamenti selettivi che emergono nel mantenimento e nella gestione del software tra i rami.