git cherry-pick: portare un commit da un’altra parte

git cherry-pick prende il cambiamento introdotto da un commit e lo applica sul branch corrente creando un nuovo commit.

È una chirurgia mirata: utile quando vuoi portare un fix, non tutta la storia del branch da cui proviene.

Perché questa lezione conta

Nel lavoro reale capita spesso:

1. un bugfix su main deve andare anche su release/1.2;
2. un commit utile è finito in un branch sperimentale;
3. una patch deve essere backportata;
4. una PR contiene un commit buono e altri non pronti.

Cherry-pick risolve questi casi senza mergeare tutto.

Obiettivo operativo

Alla fine della lezione devi saper scegliere un commit, applicarlo su un altro branch, gestire conflitti, usare -x quando serve tracciabilità e riconoscere quando cherry-pick è il sintomo di un workflow confuso.

Come funziona

git switch release/1.2
git cherry-pick abc1234

Git calcola il diff introdotto da abc1234 rispetto al suo parent e prova ad applicarlo sul branch corrente.

Il nuovo commit avrà un nuovo hash perché parent e contesto sono diversi.

-x per tracciabilità

Per backport o release branch:

git cherry-pick -x abc1234

Aggiunge al messaggio:

(cherry picked from commit abc1234...)

Questo aiuta a capire da dove arriva la patch.

Cherry-pick multiplo

Puoi applicare più commit:

git cherry-pick a1b2 c3d4 e5f6

Oppure un range:

git cherry-pick A..B

Attenzione: cherry-pick massivo spesso indica che forse volevi un merge o un rebase.

Conflitti

Se c’è conflitto:

git status
# risolvi file
git add file
git cherry-pick --continue

Per annullare:

git cherry-pick --abort

Per saltare il commit corrente:

git cherry-pick --skip

Usa --skip solo se hai capito che quel commit non è applicabile o necessario.

Quando usarlo

Usa cherry-pick per:

1. hotfix da portare su release branch;
2. recupero di un singolo commit;
3. backport controllato;
4. patch isolata da branch non pronto.

Evitalo per:

1. integrare feature complete;
2. spostare dieci commit correlati;
3. aggirare conflitti di merge;
4. copiare lavoro senza capire dipendenze.

Dipendenze tra commit

Un commit può dipendere da commit precedenti. Se cherry-picki solo il secondo, può non compilare.

Prima:

git show --stat abc1234
git show abc1234
git log --oneline --graph --decorate --all

Chiediti:

1. introduce simboli usati altrove?
2. richiede migrazioni o config?
3. dipende da refactor precedenti?
4. ha test collegati?

Controllo dopo il cherry-pick

Dopo un cherry-pick riuscito non fermarti al fatto che Git non segnali conflitti. Il branch target può avere vincoli diversi: dipendenze più vecchie, feature flag assenti, schema database differente o test non presenti.

Routine minima:

git show --stat HEAD
git diff HEAD~1..HEAD
npm test

Se stai facendo backport su release branch, aggiungi una nota nella PR: commit sorgente, motivo del backport, test eseguiti e motivo per cui non è stato fatto un merge completo.

Laboratorio guidato

Crea:

1. main;
2. release/1.0;
3. un commit bugfix su main;
4. un commit feature su main.

Porta solo il bugfix su release/1.0 con cherry-pick -x. Verifica che la feature non sia entrata.

Poi crea un conflitto e risolvilo.

Output atteso

Una procedura backport:

1. identifico commit fix
2. controllo dipendenze
3. switch release branch
4. cherry-pick -x
5. test
6. push/PR

Errori comuni

Cherry-pick di commit dipendenti. Il fix sembra isolato ma non lo è.

Cherry-pick massivo. Crea duplicati e rende difficile seguire la storia.

Dimenticare -x nei backport. Perdi tracciabilità.

Non testare sul branch target. Applicare patch non garantisce compatibilità.

Checklist di verifica

• so usare git cherry-pick <sha>;
• so usare -x nei backport;
• so continuare o abortire dopo conflitto;
• controllo dipendenze del commit;
• uso cherry-pick come intervento mirato.

Collegamenti

• Modulo: Riscrivere la storia: rebase, amend, cherry-pick — lezione 19 del corso.
• Si collega a release branch e GitFlow del modulo 6.