Git & Tricks – Pillole di source code management | Parte 2: gestire i commit con empatia

Dopo la prima puntata dedicata all’introduzione di Git ed alla preparazione dell’ambiente operativo, ecco un’altra serie di pillole dedicate questa volta alla gestione dei commit, vera linfa vitale del sistema di gestione dei codici sorgente creato da Linus Torvalds.

In cosa consiste un commit

Anche se nello scorso articolo, durante l’inizializzazione del repository di test, erano già stati effettuati alcuni commit, l’aver dato per scontato quella nozione impone di approfondirla ora, in modo da fugare il campo da ogni dubbio.

Un commit in Git è una singola unità di lavoro che include le modifiche effettuate all’interno di un repository, accompagnate da un messaggio che descrive quali queste siano state.

La sequenza di operazioni che registrano un commit è la seguente:

L’operazione consente di registrare la variazione che è stata apportata nel repository all’interno della cartella nascosta presente nel repository stesso il cui nome è .git. Qui verranno tracciati tutti i commit effettuati. La sua struttura è tipicamente la seguente:

Ad un occhio attento non sfuggirà il fatto che i nomi delle cartelle al di sotto della cartella objects corrispondono, parzialmente, agli hash dei commit:

Il contenuto effettivo di questi file è visionabile utilizzando il comando git cat-file che si aspetta un parametro -p contenente appunto l’hash del commit. Grazie a questo sarà possibile verificare come i file al di sotto della cartella objects contengano tutte le informazioni del repository.

Facendo un esempio pratico delle corrispondenze, si prenda il secondo commit del repository il cui hash è c84a422b268b. Il file corrispondente sarà quindi quello presente nel path objects/c8/4a422b268b957ef15723557288f7573ccf172a.

In questo file è presente la descrizione del commit, oltre che il commit precedente (parent b0634e7ad5a7531ff000da68b62d6810bad0fc7a) ed il ramo che rappresenta lo stato della cartella del repository quando questo commit è stato fatto (tree bbd8cdc095d0d7ecc037f14f54600d84fd9a93b0):

L’hash relativo a tree consentirà di osservare la struttura del repository:

Insieme al contenuto dei file che ne fanno parte:

Buone regole per i propri commit

Creazione di un branch dedicato

Quando si prevede di lavorare all’interno di un repository condiviso per apportare una o più variazioni è buona norma creare dei branch. I branch in Git consentono ai membri di un team di lavorare su diverse funzionalità in modo separato, evitando conflitti diretti, migliorando la gestione delle versioni e permettendo il controllo di qualità prima di integrare le modifiche nella branch principale.

Ecco quindi come creare un branch:

O, in forma più immediata:

A questo punto le modifiche potranno essere apportate in un ambiente isolato che verrà integrato solo mediante un ulteriore processo manuale.

Modifiche chiare, atomiche e non ripetitive

Git è nato per consentire a più persone di lavorare sullo stesso codice, pertanto vien da sé come ragionare in termini empatici nel momento in cui si sviluppa possa essere più che una buona idea.

Anche se sembra molto filosofico e poco tecnico l’aspetto dell’empatia, ossia mettersi nei panni di chi dovrà lavorare successivamente sui propri sviluppi, risulta essere cruciale nel lungo termine.

Piuttosto che generare commit immensi che modificano decine se non centinaia di righe in una sola volta, è sempre bene produrre commit sintetici che siano cioè il più possibile comprensibili in merito al loro scopo. Generare quindi commit che siano il più possibile atomici.

Allo stesso tempo, nel momento in cui ci si accorge di aver dimenticato delle parti nel proprio commit, oppure aver commesso dei typo, oppure di fronte all’esigenza di modificare solamente il titolo o la descrizione estesa, va sempre sottolineato come sia inutile, confusionario e dannoso pensare di generare tanti commit dal titolo identico o che si differenziano per un numero.

Si pensi a questa lista di commit mettendosi nei panni di chi dovrà leggerla, magari l’autore stesso, dopo 2 mesi:

• Mia nuova modifica, l’ultima giuro
• Mia nuova modifica #3
• Mia nuova modifica #2
• Mia nuova modifica #1
• Mia nuova modifica
• Mia nuova modifica

Ciascun commit magari avrà una solamente una virgola diversa dal precedente.Davvero una cattiva abitudine.

Evitare queste situazioni e guadagnare in empatia è semplice, poiché esiste un alleato fondamentale, che si chiama Amend.

Utilizzo di amend

A fronte di un errore o di una dimenticanza sarà possibile “ritornare sui propri passi” andando ad effettuare le correzioni del caso, aggiungendo i nuovi file modificati mediante git add ed infine sovrascrivendo il commit di testa con le variazioni, mediante il comando git commit --amend.

Ecco un esempio pratico, in cui un nuovo commit viene creato per poi essere corretto:

L’ultimo commit è il 44529906f938, che nel dettaglio apporta queste modifiche:

L’idea è quella di cambiare il contenuto di Settimo.txt, facendo risultare la modifica in modo che sia l’ultima effettuata, e vada quindi a sostituire quella precedente, ossia il commit 44529906f938.

Questo è possibile effettuando la modifica ed utilizzando poi l’opzione --amend di git commit, in questo modo:

Il comando innescherà l’apertura dell’editor di testo (generalmente vim) presentando quanto segue:

E qui potranno essere apportare ulteriori variazioni tanto al titolo del commit, quanto alla descrizione estesa, ciò che nella linea di comando vengono invece espresse con git commit -m 'Titolo' -m 'Descrizione estesa'.

Una volta modificate le descrizioni e salvato il contenuto (in vim si userà :wq) il nuovo stato dei commit sarà il seguente:

A balzare all’occhio è il nuovo hash dell’ultimo commit in ordine di tempo, ora 9d49e2580e5a, ma vale la pena far notare come il vecchio, 44529906f938, per quanto non appaia in elenco rimanga comunque accessibile e sia presente nella cartella .git:

Questo è un altro aspetto da tenere a mente per quanto riguarda Git: nulla, per fortuna, viene dimenticato.

Conclusioni

Nelle prossime puntate della serie vedremo come effettuare il merge del proprio commit nel branch main, come editare massivamente i commit utilizzando il rebase interattivo e come sfruttare il rebase classico per tenere aggiornato il proprio branch mentre lo si sta modificando.

Ma non finisce qui, perché la creazione di branch ordinate che permettano di formulare liste di modifiche chiare e comprensibili passa anche da altri utilizzi di Git, uno su tutti il cherry-pick, una funzionalità apparentemente oscura, ma indispensabile agli occhi di quanti la padroneggiano.

La serie sino ad ora

Git & Tricks – Pillole di source code management | Parte 1: un ambiente confortevole

Git & Tricks – Pillole di source code management | Parte 2: gestire i commit con empatia