Git rebase interattivo in una GUI: squash, correzione, riformulazione, riordino e eliminazione dei commit

Una GUI rebase interattiva ti consente di riscrivere i commit sul tuo ramo da un elenco invece che da un file di testo: scegli un commit iniziale, assegna a ogni commit sopra di esso un'azione (scegli, schiaccia, correggi, riscrivi, modifica o rilascia), trascinali in un nuovo ordine e lascia che Git li riproduca. Esegue la stessa operazione di git rebase -i, quindi il risultato è identico alla riga di comando. In GitTree fai clic con il pulsante destro del mouse sul commit appena sotto quelli che desideri modificare, scegli Rebase interattivo dei commit sopra…, imposta le azioni e fai clic su Start Rebase. Se il risultato è sbagliato, Annulla ripristina il ramo.

Questo tutorial interattivo sul rebase copre ogni azione, tre modi per schiacciare i commit, i comandi corrispondenti, l'autosquash e la rete di sicurezza. Gli screenshot mostrano l'editor interattivo di rebase di GitTree, un client Git per macOS, Windows e Linux, ma il comportamento Git è lo stesso in qualsiasi strumento.

Cosa fa il rebase interattivo di Git e quando usarlo

Un normale rebase sposta una serie di commit su una nuova base. Un rebase interattivo ti consente anche di modificare quella serie lungo il percorso: Git mostra i commit che sta per riprodurre, tu cambi l'elenco e Git ricostruisce il ramo in modo che corrisponda. Ogni commit riscritto riceve un nuovo ID, motivo per cui il rebase interattivo appartiene alla fase precedente alla condivisione del tuo lavoro. Motivi tipici per raggiungerlo:

• Riduci una serie di commit "wip", "correzione errore di battitura" e "revisione indirizzo" in un commit significativo prima di aprire una richiesta pull.
• Riformulare un messaggio di commit che contiene un errore di battitura, un numero di ticket mancante o un riepilogo vago.
• Ripiega una modifica dimenticata nel commit a cui appartiene, in modo che ogni commit si crei da solo.
• Riordina i commit in modo che un refactor si trovi prima della funzionalità che dipende da esso.
• Elimina un commit di debug o un esperimento che non dovrebbe mai raggiungere il ramo principale.

Scegli, schiaccia, correggi, riformula, modifica e rilascia: spiegate le azioni di rebase

Ogni riga in un piano di rebase interattivo corrisponde a un commit più un'azione. Questi sono quelli che utilizzerai giorno per giorno (il file delle cose da fare di Git ne ha alcuni altri per lo scripting, come exec e break):

L'ordine è importante ed è l'opposto di `git log`. Il piano elenca il commit più vecchio in alto, in ordine di riproduzione, mentre git log e la maggior parte dei grafici dei commit mostrano prima il più recente. Uno squash o una correzione si fondono sempre nel commit direttamente sopra di esso, quello più vecchio. Se uno squash finisce in cima senza nulla in cui piegarsi, GitTree si rifiuta di iniziare finché non lo sposti sotto un commit che mantieni.

L'equivalente da riga di comando: git rebase -i

Sulla riga di comando dai un nome al commit appena sotto quelli che vuoi modificare: conta all'indietro da HEAD o usa il punto in cui il tuo ramo ha lasciato main.

# rewrite the last 5 commits
git rebase -i HEAD~5

# rewrite everything since the branch left main, without moving its base
git rebase -i $(git merge-base main HEAD)

Git apre il tuo editor con un elenco di cose da fare. Questo è lo stesso piano dello screenshot più in basso: il secondo commit è schiacciato nel primo e il quarto riceve un nuovo messaggio.

pick f2cd67d chore(deps): upgrade Next.js and React
squash 19a1104 ci: cache pnpm store and run tests in parallel
pick f52edc8 refactor(api): extract repository layer from handlers
reword 05dfac2 feat(api): rate limit public endpoints
pick bf2385e fix(web): focus trap in the invite dialog

Salva e chiudi il file e Git inizia la riproduzione. Richiede il messaggio squash e il messaggio riformulato e si ferma su qualsiasi passaggio o conflitto edit, in cui continui o ti arrendi:

git rebase --continue   # after amending or resolving a conflict
git rebase --abort      # stop and put the branch back where it was

Una GUI cambia il modo in cui scrivi il piano, non ciò che Git ne fa. GitTree esegue lo stesso piano con Git già installato sul tuo computer (versione 2.39 o successiva), quindi l'app e un terminale producono gli stessi commit. Per compromessi più ampi, leggi Git GUI vs riga di comando.

Come schiacciare i commit in una GUI Git

La risposta breve a come schiacciare i commit: mettili uno accanto all'altro, lascia il primo come scelta, contrassegna il resto come squash o correzione e riproduci. GitTree ti offre tre modi per arrivarci.

Comprimi un gruppo di commit nell'editor di rebase

Apri l'editor dal commit sotto il gruppo, imposta il primo commit su Pick e gli altri su Squash o su Fixup se non vuoi i loro messaggi. Trascina i commit randagi in posizione se il gruppo non è contiguo. GitTree visualizza in anteprima ogni gruppo che contiene uno squash come il commit che diventerà, con il messaggio combinato in una casella che puoi modificare.

Seleziona i commit nel grafico e scegli Squash Commits

Per uno squash veloce, seleziona due o più commit consecutivi del ramo corrente nel grafico, fai clic con il pulsante destro del mouse e scegli Squash Commits. GitTree esegue il rebase per te e Annulla può ripristinare i commit separati. Lo stesso menu riscrive i singoli commit in un unico passaggio: Modifica messaggio di commit…, Rilascia commit…, Sposta commit su e Sposta commit giù. Queste scorciatoie funzionano sui commit che non sono ancora su un telecomando; per i commit push, utilizza l'editor, che ti chiede prima di confermare.

Squash quando unisci la richiesta pull

Se il tuo team mantiene un commit per richiesta pull, potrebbe non essere necessario riscrivere affatto il ramo: la visualizzazione della richiesta pull di GitTree può fondersi con squash e il tuo ramo locale rimane com'era.

Correggi commit e autosquash: correggi un vecchio commit senza riordinarlo manualmente

Mentre lavori, esegui il commit di ogni piccola correzione come correzione del commit a cui appartiene; Git lo intitola fixup! <original title>. Successivamente, un rebase interattivo con autosquash sposta ogni correzione direttamente sotto la sua destinazione e la contrassegna come corretta, quindi tutto ciò che fai è controllare l'elenco e iniziare.

# record a correction for an earlier commit
git commit --fixup=05dfac2

# correct the commit and replace its message too
git commit --fixup=amend:05dfac2

# later: fold every fixup! and amend! commit into its target
git rebase -i --autosquash main

# turn autosquash on for every interactive rebase
git config --global rebase.autoSquash true

In GitTree, esegui questi comandi nel terminale integrato agganciato sotto il grafico oppure digita fixup!, uno spazio e il titolo originale nella finestra del messaggio di commit; Git abbina le correzioni in base al titolo, quindi entrambi creano lo stesso commit. Con la Riparazione Organizza!, schiaccia! e modificare! commit, l'editor si apre già organizzato e quello che vedi è esattamente ciò che Git esegue.

Un commit amend! diventa fixup -C nel piano (“Fixup, usa il suo messaggio” in GitTree): le sue modifiche vengono ripiegate e il suo messaggio sostituisce quello del target. Secondo la documentazione git-commit, nessuno dei due tipi cambia chi ha creato il commit originale.

Il rebase interattivo è sicuro? Annulla, reflog e force-with-lease

Un rebase non elimina immediatamente i vecchi commit: rimangono raggiungibili dal reflog finché la garbage collection di Git non cancella gli oggetti irraggiungibili molto più tardi. I rischi reali sono perdere traccia della vecchia filiale e sovrascrivere il lavoro di un collega da remoto.

Annulla un rebase finito

GitTree esegue uno snapshot del ramo prima di ogni rebase, quindi Annulla nella barra degli strumenti lo ripristina con un clic, inclusi gli altri rami spostati dal rebase con update-refs, purché da allora nulla abbia spostato il ramo. Come annullare un git reset, rebase o commit copre il resto della rete di sicurezza. Sulla riga di comando:

# still in the middle of the rebase
git rebase --abort

# already finished: go back to the tip from before the rebase
git reflog show --date=relative
git reset --hard ORIG_HEAD

Git imposta ORIG_HEAD sul vecchio suggerimento quando inizia un rebase, ma un'esecuzione di git reset durante il rebase (per dividere un commit, ad esempio) lo sposta. Subito dopo il rebase, @{1}, la posizione precedente del ramo corrente, punta ancora al vecchio tip, quindi anche git reset --hard @{1} funziona. git reset --hard elimina le modifiche non salvate, quindi prima confermale o mettile da parte.

La riscrittura impegna i commit che hai già inviato

GitTree etichetta i commit già presenti su un telecomando con "Su un telecomando" e ti chiede di confermarli prima di riscriverli. Successivamente una spinta normale viene rifiutata, quindi è necessaria una spinta forzata. Utilizza il modulo di locazione, che sovrascrive il ramo remoto solo se punta ancora dove l'hai visto l'ultima volta:

git push --force-with-lease

# safer when something fetches in the background
git push --force-with-lease --force-if-includes

Un recupero in background può aggiornare il tuo ramo di monitoraggio remoto e indebolire il lease, quindi la documentazione git-push suggerisce di aggiungere --force-if-includes. In GitTree un push forzato utilizza sempre --force-with-lease, aggiunto al suggerimento remoto mostrato quando confermi, e quel suggerimento viene mantenuto localmente sotto refs/ogt/trash, quindi i commit che rimuove dal remoto non vengono persi. L'annullamento non può invertire una spinta forzata, perché ha cambiato il telecomando.

Quando un passaggio si interrompe: modifiche e conflitti

Un passaggio edit o un commit che non si applica più in modo corretto mette in pausa il rebase. GitTree mostra l'avanzamento del piano e un banner per continuare o interrompere. I conflitti si aprono nell'editor a tre vie, trattato in risoluzione dei conflitti di unione in una GUI. Durante un rebase Git scambia i lati di una fusione: "nostro" è il ramo su cui stai rebasando e "loro" è il tuo commit, quindi GitTree li etichetta "rebasing su" e "tuo commit". La lezione Continua, salta o interrompi un'operazione attiva mette in pratica ogni scelta e per copiare un singolo commit invece di riscrivere un ramo, vedi cherry-pick.

Suggerimenti per una cronologia dei commit pulita prima di una richiesta pull

• Fai in modo che ogni commit venga compilato e superi i suoi test da solo e mantieni separate le modifiche non correlate: un commit per il refactoring, uno per la funzionalità.
• Effettua il rebase all'ultimo main prima di aprire la richiesta pull, in modo che i revisori vedano solo le modifiche.
• Lavori con rami impilati? Attiva update-refs in modo che i rami costruiti sul tuo si spostino con i commit riscritti.
• Se l'intervallo contiene un commit di unione, GitTree lo mostra ma non lo riscriverà; utilizzare git rebase -i --rebase-merges per quel caso.
• Controlla il risultato nel grafico di commit prima di inviare e lascia che sia la tua CLI di codifica AI a elaborare i messaggi, come in Messaggi di commit AI con Claude Code e Codex.
• Esercitati prima su un repository usa e getta con la lezione gratuita Rebase di lavori non pubblicati su una nuova base.

GitTree ha un piano gratuito che copre tutte le funzionalità Git, repository privati inclusi, su macOS, Windows e Linux, in English and Arabic; Nour, l'assistente AI, viene fornito con GitTree Pro (vedi prezzi). Sono necessari Git 2.39 o più recenti e un account GitTree per accedere. Ottienilo dalla pagina di download o confronta prima i migliori client GUI Git.