Git & Tricks – Pillole di source code management | Parte 3: l’importanza del rebase per un mondo migliore

Nella puntata precedente è stato affrontato il valore della coerenza nel gestire i commit relativi ai propri sviluppi, sottolineando come descrizioni chiare, estese e l’utilizzo di amend possano fare la differenza nella gestione a lungo termine del proprio repository.

Rimanendo dello stesso ambito, questa puntata esplora l’importanza di una corretta gestione dei contributi, andando a sviscerare le differenze tra merge e rebase.

In cosa consiste un merge

Nello scorso articolo è stato esplorato il concetto di branch, andando a creare quindi una variante (i fan di Loki capiranno di che cosa si sta parlando in un attimo) del ramo principale del repository, ossia main.

Rimane quindi da capire quali sono le azioni da compiere per far sì che le variazioni presenti nel branch alternativo diventino parte di quello principale. Rimane cioè da capire il concetto di merge, ossia unione.

Dato un branch, in questo caso mio-contributo, contenente una modifica che non esiste nel branch main:

Per far sì che questa ne diventi parte si potrà usare il comando git merge, passando come parametro il nome del branch che si vuole unire, in questo caso quindi mio-contributo:

Da questo momento le modifiche che sono presenti nel branch alternativo saranno parte anche del branch principale:

HEAD è quindi riferimento comune per entrambi i branch. Preciso, pulito, semplicissimo… In un mondo perfetto, denso di unicorni e arcobaleni.

Gestione dei conflitti

I branch e le varianti in esso presenti fintanto che operano su file diversi possono funzionare in maniera molto lineare, ma cosa succede quando le varianti operano sugli stessi file? Come si gestiscono i conflitti?

Ripartendo dalla precedente situazione iniziale:

All’interno del branch main si andrà ad aggiungere un commit che modifica Settimo.txt, lo stesso file modificato nel branch mio-contributo:

La situazione è quindi di conflitto.

Se si provasse ad effettuare un merge del branch mio-contributo all’interno del branch main questi fallirebbe. In queste situazioni quindi è necessario sanare manualmente i conflitti, modificando la propria prospettiva. È infatti all’interno del branch variante mio-contributo che si opererà, in modo da renderlo compatibile con un merge “pulito” come quello mostrato in apertura.

Ci sono sostanzialmente due modi per raggiungere il risultato: sanare i conflitti mediante merge oppure mediante rebase.

Utilizzo di merge

L’allineamento del branch mio-contributo con main utilizzando merge rivelerà cosa c’è da risolvere:

Il problema è chiaro: entrambi i commit hanno modificato lo stesso file, quindi va gestito il conflitto che, all’interno del file apparirà evidenziato così:

si capisce come la porzione inclusa tra <<<<<<< HEAD e ======= sia relativa alle modifiche del branch attuale, mentre l’altra, da ======= a >>>>>>> main sia relativa a quanto vogliamo includere.

Una volta ricomposto il file secondo le aspettative, ad esempio in questo modo:

Sarà possibile completare il merge:

L’operazione comporterà l’apertura dell’editor vim, che consentirà di inserire un messaggio esteso per il commit di merge:

Salvando ed uscendo dall’editor (:wq) un nuovo commit (il merge, appunto) verrà aggiunto nella sequenza:

L’alberatura ha subito una variazione, ma ora comprende anche il commit presente nel branch main, pertanto il merge del branch mio-contributo nel branch main avverrà senza colpo ferire:

HEAD è ora allineato ad entrambi i branch, che quindi sono identici, anche se esteticamente la situazione lascia un poco a desiderare in termini di comprensione.

Utilizzo di rebase

Considerando la stessa situazione di partenza, lo stesso processo può essere eseguito utilizzando rebase:

Dal branch mio-contributo anziché merge si effettuerà un rebase di main:

Anche in questo caso esiste lo stesso conflitto (non potrebbe essere altrimenti), e si può gestire in maniera identica al precedente, sistemando il contenuto del file Settimo.txt:

E continuando l’operazione di rebase:

La differenza sostanziale è che ad essere creato sarà un nuovo commit, basato sul precedente, e non un commit di merge:

Il che comporterà, una volta completato l’editing ed usciti dal terminale vim, questa sequenza di commit:

Rispetto al risultato ottenuto in precedenza con il merge, la lista dei commit è decisamente più lineare, e sarà anche più facilmente integrabile nel branch main:

Come si può notare nella lista dei commit HEAD corrisponde tanto al branch main quanto a mio-contributo. Tutte le variazioni sono state mantenute, ma a differenza della situazione ottenuta con il merge, il rebase in questo caso garantisce molta più linearità, garantendo anche una gestione dei commit più mirata, anche in caso di annullamento delle modifiche, ad esempio mediante git revert.

Conclusioni

Quanto sia preziosa una lista di commit lineare rispetto ad una intersecata e con mille diramazioni è letteralmente incalcolabile. Il tutto concorre ancora una volta al tema principale che aleggia questa serie: l’empatia. Mettersi nei panni di chi dovrà un domani gestire il repository, spendendo qualche minuto in più per rendere la vita più facile in termini di comprensione e gestione, fa di noi delle persone migliori.

Alla prossima puntata!