Guide galattiche per aspiranti programmatori

Una doverosa precisazione: l’uso del comando git rebase in Git che vedremo in questa sezione sarà focalizzato solo sulla possibilità offerta di modificare uno o più commit più vecchi dell’ultimo salvato, ovvero l’esecuzione in modalità interactive.
Vedremo la modalità standard git rebase (e il suo vero significato) in un altro capitolo.

Come suggerisce il nome, la modalità interactive richiede di interagire con il comando durante la sua esecuzione, per istruirlo sul da farsi.

Per prima cosa è necessario individuare il commit o il gruppo di commit da modificare nelle history, in particolare “quanti commit fa” è il primo commit che si vuole cambiare. Nell’esempio di history mostrato a inizio della sezione, vorremmo poter cambiare i commit a partire dal quinto più vecchio (35dec0e trying adding profile page). In questo caso si userà il comando

git rebase --interactive HEAD~5

In cui la dicitura HEAD~5 istruisce Git a prepararsi per modificare uno o tutti gli ultimi 5 commit.

Nel momento in cui viene avviato il procedimento interattivo di git rebase, viene aperto l’editor di default con un contenuto simile al seguente:

pick b2b95ad wip - unfinished
pick edb709f profile mostly works, missing phone number
pick af75ac9 update indentation for checks from linter
pick 35dec0e increase version
pick 5dd0865 make variable names more clear
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
 [...]

Nella prima parte è presente l’elenco dei commit selezionati, dal più vecchio al più recente – quindi in ordine inverso rispetto a git log – ognuno dei quali è preceduto da comando di rebase, di default pick. Ciascuna riga è così composta:
 

<COMANDO> <COMMIT_ID> <COMMIT_MESSAGE>.

Solo i primi due sono necessari a git rebase, il messaggio di commit serve a chi andrà a chiedere quali modifiche fare per avere un riferimento del contenuto del commit.

Nella seconda parte è riportata la spiegazione dei vari comandi di rebase sotto forma di commento.

Salvando e chiudendo questo testo in modo analogo a quanto succede con la scrittura del messaggio di commit, git rebase proverà ad applicare a ciascuno dei 5 commit selezionati il comando fornito. Se non si applicano modifiche, git rebase si limiterà a ri-applicare le stesse modifiche. In pratica quindi non farà nulla.

Nel caso del nostro esempio, il nostro intento era quello di ottenere due commit: uno con tutte le modifiche necessarie a implementare una certa feature e uno con le sole modifiche che salvano nel progetto la nuova versione. In base al nostro intento e al contenuto dei commit effettivamente a disposizione, le indicazioni da dare a git rebase cambieranno quindi di volta in volta.

Proviamo a delineare come procedere. Nel nostro caso vogliamo riunire insieme tutti i commit che cambiano il codice sorgente per implementare una certa funzione e cambiare messaggio di commit al commit che cambia solo la versione del progetto, lasciando questo come commit finale. In tale caso, possiamo istruire git rebase ad applicare i seguenti comandi:

pick b2b95ad wip - unfinished
squash edb709f profile mostly works, missing phone number
squash af75ac9 update indentation for checks from linter
squash 5dd0865 make variable names more clear
edit 35dec0e increase version

Per poter unire dei commit insieme è necessario prendere il più vecchio (pick) e istruire git rebase a “schiacciare insieme” (squash) quello immediatamente successivo.
Le prime 4 righe riportate qui sopra istruiscono, quindi, git rebase a unire quattro in un solo commit.

L’ultima riga dice di mantenere il contenuto del commit così com'è, ma di cambiarne il messaggio (edit).

Una cosa importante da notare: per poter unire insieme tutti i commit che andavano a fare modifiche, abbiamo cambiato l’ordine con cui i commit iniziali comparivano nella history del progetto (il commit 5dd0865 e 35dec0e sono stati invertiti nell’ordine di applicazione dei comandi). Non sempre è possibile invertire l’ordine di applicazione dei commit, ma in questo nostro caso ipotetico era possibile farlo perché i due commit di partenza apportavano modifiche a file diversi. Torneremo su questa tematica più avanti.

Salvando e chiudendo il file, git rebase procederà ad applicare i comandi ricevuti fino a che non sarà necessario l’intervento dell’utente.

La prima richiesta sarà quella di fornire un nuovo messaggio di commit per i commit “uniti”.

# This is a combination of 4 commits.
# This is the 1st commit message:
wip - unfinished
# This is the commit message #2:
profile mostly works, missing phone number
# This is the commit message #3:
update indentation for checks from linter
# This is the commit message #4:
make variable names more clear
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.

Vengono riportati, per convenienza, i messaggi dei commit che si stanno unendo, ma è possibile cancellare tutto e scriverne uno nuovo da zero. Una volta scritto il messaggio desiderato, è sufficiente salvare ed uscire dall’editor per continuare.

La seconda richiesta di intervento arriverà nel gestire l’ultimo commit che faceva parte del rebase.

In questo caso, avendo scelto edit, git rebase non vi chiederà semplicemente di inserire il nuovo messaggio di commit, ma si farà temporaneamente da parte lasciando spazio alla esecuzione di altri comandi.

$ git rebase --interactive HEAD~5
Stopped at 35dec0e... increase version
You can amend the commit now, with
git commit --amend
Once you're satisfied with your changes, run
git rebase --continue
$

In questo caso, le istruzioni fornite dicono esattamente cosa fare: eseguire un git commit –amend che ci permette di cambiare il messaggio del commit, seguito poi da git rebase –continue per procedere nell’esecuzione del rebase.

Se tutto sarà andato a buon fine, git rebase vi premierà con un incoraggiante messaggio rebase successful.

Se qualcosa dovesse andare storto, nel momento in cui il processo si interrompe per avvisare dell’impossibilità di procedere, potrebbero essere riportare a schermo istruzioni utili a risolvere il problema. In questi frangenti, è comunque possibile eseguire un git rebase –abort per annullare l’esecuzione del rebase.

Nel momento in cui l’esecuzione del rebase va a buon fine, i commit modificati sono persi, sostituiti dai nuovi nella history.

Per cominciare a prendere confidenza con git rebase e la sua modalità interactive, il consiglio è quello di provare a creare piccoli commit “indipendenti”, sui quali poi fare qualche rebase per unirli, cambiarne ordine, e simili. 

git rebase è uno dei comandi più “potenti” di Git, poiché permette di modificare la history del repository. Padroneggiarne al meglio l’ utilizzo potrebbe non essere immediato, ma a rendere le cose più semplici o più difficili concorre anche l’esatto contenuto delle cronologia dei commit da cambiare/riorganizzare/rifare/… 

È sempre importante fare attenzione a quali modifiche andranno a far parte di un commit (e in quale ordine), perché anche da questo dipende la possibilità futura di riorganizzare la history delle proprie modifiche prima di renderle pubbliche.