Il tuo branch di funzionalità è indietro rispetto a main e ti serve il lavoro nuovo. Git merge vs rebase è la scelta tra due modi per ottenerlo, ed entrambi sono corretti. Cambia l’aspetto della cronologia dopo.

Abbiamo creato un piccolo repository, eseguito entrambi i comandi e incollato l’output reale qui sotto, così confronti il risultato invece di immaginarlo. Sei nuovo con Git? Parti dal nostro tutorial Git per principianti (in inglese).

Cosa fanno git merge e git rebase

git merge prende le punte di due branch e le combina. Se entrambi hanno commit nuovi, Git crea un commit di merge con due genitori. Nulla di ciò che esiste viene modificato.

git rebase prende i commit presenti solo nel tuo branch, li mette da parte, sposta il branch sulla punta dell’altro e poi li riapplica uno alla volta. I commit riapplicati sono commit nuovi con hash nuovi, anche se le modifiche sono le stesse.

Git merge in pratica

Il nostro punto di partenza: commit A su main, due commit (F1, F2) su feature e un altro commit (M1) aggiunto dopo a main. Ora facciamo il merge di main in feature.

git switch feature
git merge main
git log --oneline --graph

*   f507aab Merge main into feature
|\
| * 8842fb5 M1
* | 082cc6a F2
* | 5a71e3c F1
|/
* 8766865 A

Il grafo mostra la storia reale: due linee di lavoro che sono state unite. I commit originali F1 e F2 mantengono i loro hash. Il costo è un commit di merge in più e, in un progetto attivo, il grafo diventa una ragnatela.

Git rebase in pratica

Stesso punto di partenza, ma questa volta facciamo il rebase di feature su main.

git switch feature
git rebase main
git log --oneline --graph

* 1ff474b F2
* bf9149e F1
* 8842fb5 M1
* 8766865 A

La cronologia è una linea retta, come se avessi iniziato dopo M1. Guarda gli hash: F1 era 5a71e3c e ora è bf9149e, mentre F2 è passato da 082cc6a a 1ff474b. Git li ha riscritti, ed è per questo che il rebase richiede attenzione.

Merge e rebase a confronto

La regola d’oro del rebase

Non fare il rebase di commit che esistono fuori dal tuo repository. Dopo un rebase il tuo branch non coincide più con la copia sul server, quindi per inviarlo serve un push forzato. Se un collega ha costruito lavoro sui vecchi commit, la sua cronologia ora diverge dalla tua e sistemarla è doloroso.

Fare il rebase del tuo branch di funzionalità privato va bene. Farlo su main o su qualsiasi branch usato da altri, no.

Un flusso di lavoro sicuro per il team

Questa routine mantiene pulita la cronologia senza sorprendere nessuno. È anche ciò che la maggior parte dei team usa prima della pipeline CI, come quella della nostra guida a GitHub Actions CI/CD (in inglese).

git switch feature
git fetch origin
git rebase origin/main        # or: git pull --rebase
# fix conflicts, then: git add <file> && git rebase --continue
git push --force-with-lease   # only on your own branch

--force-with-lease si rifiuta di sovrascrivere il branch sul server se qualcuno ha fatto push dopo il tuo ultimo fetch, cosa che un semplice --force distruggerebbe in silenzio. Quando la pull request è approvata, fai il merge in main.

Come annullare un rebase sbagliato

Un rebase sembra distruttivo, ma i vecchi commit restano per un po’ nel reflog di Git, quindi puoi tornare indietro.

git reflog                    # find the commit before the rebase
git reset --hard HEAD@{5}     # example position, check reflog first

Crea un branch di backup con git branch backup prima di ogni rebase rischioso e il ripristino diventa un solo comando. Esegui database o strumenti nei container? Guarda il nostro tutorial Docker per principianti (in inglese).

Conclusioni

Il merge conserva la verità, il rebase la tiene in ordine. Usa il rebase per aggiornare il tuo branch, il merge per consegnarlo e non riscrivere mai una cronologia da cui dipendono altri.

Domande frequenti

Continua a imparare (articoli in inglese)