Ramo Git rebase: come rebase in sicurezza, passo dopo passo

Per ribasare un ramo, recupera, passa ad esso e riproducilo sulla nuova base: `git fetch origin`, `git switch topic`, `git rebase origin/main`. Git mette da parte i commit del tuo ramo, sposta il ramo all'estremità di origin/main, quindi riapplica i commit uno alla volta. La cronologia rimane una linea retta senza commit di unione. Ogni commit riprodotto riceve un nuovo hash, quindi un ramo che hai già inviato necessita di git push --force-with-lease in seguito.

Cosa fa git rebase a un ramo?

Supponiamo che topic abbia due commit propri e main ne abbia guadagnati tre dall'inizio del ramo. Ribasare gli aggiornamenti del punto di partenza senza unire main nel tuo ramo:

# before
A---B---C---D---E   origin/main
     \
      F---G         topic

# after git rebase origin/main
A---B---C---D---E   origin/main
                 \
                  F'---G'   topic

F' e G' contengono le stesse modifiche e messaggi di F e G, ma sono nuovi commit con nuovi hash, perché i loro genitori sono cambiati. Un'unione dallo stesso punto di partenza manterrebbe entrambe le righe e aggiungerebbe un commit con due genitori. La lezione su merge versus rebase mostra entrambi su un grafico.

Come posso riorganizzare un ramo in modo sicuro, passo dopo passo?

Ispeziona prima, conserva il vecchio suggerimento, riproduci, quindi prova. I primi tre comandi non riscrivono nulla:

# 1. update origin/main, your files stay as they are
git fetch origin

# 2. list the commits Git will replay
git log --oneline origin/main..topic

# 3. keep a name on the old tip
git branch topic-backup topic

# 4. replay
git switch topic
git rebase origin/main

Fermati al passaggio 2 se l'elenco ha un commit che non riconosci, perché significa che il ramo non è iniziato dove pensavi. Al termine del rebase, esegui git status per confermarne il completamento, quindi esegui i test. Un rebase senza conflitti può comunque interrompere il comportamento.

Dai un nome alla base ogni volta. Un semplice git rebase utilizza l'upstream del ramo, che spesso è origin/topic e non main. Per spostare un ramo che partiva da un altro ramo della caratteristica, nominare anche la vecchia base: git rebase --onto main old-base topic. La lezione su ribasare il lavoro inedito mette in pratica questo su un grafico reale.

Come posso risolvere i conflitti durante un rebase?

Git applica i tuoi commit uno alla volta, quindi può interrompersi più di una volta, anche nelle stesse righe. Correggi solo il commit su cui Git si è interrotto, poiché quelli successivi non sono ancora stati applicati:

# edit the file and remove the conflict markers, then
git add path/to/file
git rebase --continue

Se riproduci spesso lo stesso conflitto, git config rerere.enabled true registra la tua risoluzione e la riutilizza. Controlla ogni risultato riutilizzato, perché la risposta di ieri può essere sbagliata nel codice di oggi. La lezione su continua, salta e interrompi esamina ciascun caso e come risolvere i conflitti di unione copre la lettura dei marcatori.

Come posso controllare un rebase prima del push?

Confronta la vecchia serie con quella nuova prima che qualcun altro la veda:

# old and new commits, matched pair by pair
git range-diff origin/main topic-backup topic

# everything the branch adds to main, as one diff
git diff origin/main...topic

# the shape of the history
git log --graph --oneline --decorate origin/main topic

git range-diff mostra quando la risoluzione di un conflitto ha modificato una patch o quando un commit è andato perduto. Il codice che viene compilato può comunque nascondere un test interrotto o una condizione modificata, ed è qui che lo scopri.

Come posso annullare un rebase?

Mentre è in esecuzione, utilizza git rebase --abort. Una volta terminato, sposta nuovamente il ramo sulla vecchia punta. Controlla prima git status, perché --hard scarta le modifiche non salvate:

git reset --hard topic-backup

# no backup? find the old tip in the reflog
git reflog show topic
git reset --hard <old-tip-hash>

La guida su annullare un ripristino, un rebase o un commit copre il reflog in modo più approfondito.

Come faccio il push di un branch dopo il rebase?

Un push normale viene rifiutato, perché il ramo remoto conserva ancora i vecchi commit e Git vede un aggiornamento non veloce. Controlla cosa stai per sostituire, quindi invia un contratto di locazione:

git fetch origin
git log --oneline topic..origin/topic
git push --force-with-lease origin topic

Quel git log dovrebbe elencare solo i tuoi vecchi commit. Tutto il resto è lavoro di un compagno di squadra, quindi fermati e portalo dentro per primo. --force-with-lease sostituisce il ramo remoto solo se è ancora dove l'ultimo recupero lo ha visto e il semplice --force non ha tale controllo. I recuperi in background aggiornano quel valore, quindi gli script possono nominare il commit che si aspettano: git push --force-with-lease=topic:<expected-hash> origin topic.

Dovrei riorganizzare o unire questo ramo?

La guida per ribasare un ramo ha tutte le opzioni e forzare il push con lease copre il push. Per schiacciare, riformulare o riordinare lungo il percorso, leggi rebase interattivo in una GUI.