Confronta rebase e merge fianco a fianco su un grafo dei commit live, pianifica un rebase interattivo con pick, squash, fixup e drop e scopri come interrompere o annullare con il reflog.
git rebase riapplica i commit del tuo branch sopra un altro commit, ottenendo una cronologia lineare invece di un commit di merge. Esegui git rebase main dal tuo feature branch, risolvi eventuali conflitti, poi git rebase --continue. Usa git rebase -i per unire, riformulare o eliminare commit, e git rebase --abort per tornare indietro.
I comandi di rebase che digiterai più spesso
Il rebase è il comando git che fa più paura, soprattutto perché riscrive i commit. Il grafo qui sotto mostra esattamente cosa cambia quando fai merge invece di rebase, il pianificatore ti fa provare un rebase interattivo su commit di esempio, e le ultime sezioni parlano di conflitti, dell'unica regola che protegge i colleghi e di come recuperare un branch dopo un rebase andato male.
Il merge conserva la cronologia reale e aggiunge un commit di merge, la scelta più sicura per i branch condivisi. Il rebase dà una linea retta più facile da leggere e da analizzare con bisect, adatta al tuo feature branch prima della review. Molti team fanno rebase in privato e merge in pubblico.
Se è ancora in corso, git rebase --abort rimette tutto a posto. Se è già finito, esegui git reflog, trova la voce subito prima dell'inizio del rebase e fai git reset --hard a quell'hash. Anche ORIG_HEAD punta alla vecchia punta subito dopo un rebase, a meno che un altro comando non l'abbia cambiato.
Non fare il rebase di commit su cui altre persone hanno già basato il proprio lavoro. Il rebase crea nuovi commit con nuovi hash, quindi chi possiede quelli vecchi si ritrova con una cronologia duplicata e conflitti confusi.
Entrambi uniscono un commit a quello sopra. squash apre l'editor per combinare i due messaggi; fixup scarta il messaggio del commit unito e mantiene quello precedente. fixup -C invece mantiene il messaggio del commit unito.
Ogni commit viene riapplicato sulla nuova base, e un commit che ha toccato le stesse righe della base non può essere applicato automaticamente. Modifica il file, fai git add e lancia git rebase --continue. Puoi incontrare un conflitto per ogni commit riapplicato.
git rebase -i apre una todo list con una riga per commit, il più vecchio in cima. Cambia la parola all'inizio di una riga, salva e chiudi l'editor, e git esegue la lista dall'alto verso il basso.
Comandi della todo list in git rebase -i
Prima fai fetch così main è aggiornato, poi rebase, risolvi gli eventuali conflitti e pubblica in sicurezza il branch riscritto.
Trova la riga subito prima dell'inizio del rebase e riporta il branch a quel punto.
--onto accetta tre punti: la nuova base, la vecchia base e il branch. Si spostano solo i commit successivi alla vecchia base.
feature-b è stato creato a partire da feature-a. Questo mette sopra main solo i commit propri di feature-b.
Merge o rebase: cosa succede alla cronologia
Scegli come combinare i branch
Merge
Rebase
commit di merge
Il merge lascia intatti F1 e F2 e aggiunge un nuovo commit con due genitori.
Il rebase copia F1 e F2 sopra M3. Le copie (segnate con ') hanno nuovi hash; gli originali vengono abbandonati.
Pianificatore di rebase interattivo
Scegli un'azione per ogni commit, dal più vecchio, e guarda la todo list e il risultato.
Azione per il commit {n}
Todo list aperta da git
Cronologia dopo il rebase
La prima riga non può essere squash o fixup: non c'è nessun commit sopra a cui unirla.
Tutti i commit sono stati eliminati. Il branch punterebbe alla sua base.
include {n} commit unito/i
messaggio modificato
Inizia gratis · Nessuna carta di credito richiesta