Fate del bene all’umanità, tenete pulita la storia dei commit in Git!

Quando sei ossessivo-compulsivo nella ricerca di ordine ovunque ti trovi costantemente a combattere con la realtà dei fatti: ordine e caos sono bilanciati nel mondo, poiché è su questo che esso si fonda: l’equilibrio. Ora, immagino la faccia perplessa di molti, ma sono ancora su miamammausalinux.org oppure sono finito su un sito di filosofia, spiccia per giunta? In fondo, poi, c’è così tanta differenza?

Provo a spiegare.

Imbattendomi in questo brillante articolo di Chris Manson, intitolato “Git Good – The magic of keeping a clean Git history“, non ho potuto fare a meno di pensare a come la battaglia contro il caos (del mondo, o semplicemente di repository Git illeggibili per complessità) può vivere piccole vittorie se si rispettano alcuni piccoli accorgimenti, che però sono determinanti.

In estrema sintesi, e lascio ai curiosi la lettura dell’articolo che merita davvero, si può riassumere che la via verso dei repository Git vivibili passa principalmente dall’empatia. Immedesimarsi cioè nelle persone che leggeranno il proprio codice e i propri commit, provando ad immaginare quali difficoltà potrebbero avere, in termini anche solo di review del codice, a comprendere la complessità di una modifica di centinaia di righe, su decine di file diversi.

Da lì nasce uno dei dettami che sposo in pieno:

Smallest number of commits for the smallest conceptual change

Il minor numero di commit per la minor modifica concettuale

Quindi, nella sostanza, piccoli commit che siano mirati a far comprendere cosa si è voluto fare. E una regola poi:

Rule 1: Don’t waste your reviewer’s time by showing them all your failed experiments in your Git history.

Regola 1: non sprecare il tempo del tuo reviewer mostrandogli nell’history tutti gli esperimenti falliti

Pensateci: a cosa giovano tre commit che comprendono: il test della patch, il revert della patch e la patch definitiva? Non sarebbe meglio avere un solo commit?

Empatia.

Infine lo straordinario strumento per evitare ogni tipo di problema con history lunghissime: git rebase. Il giorno zero di ogni sviluppatore dovrebbe essere speso a capire la tecnica del rebase e far sì che diventi lo standard, onde evitare situazioni di questo tipo:

Nelle quali anche la persona più competente e disponibile del mondo potrebbe aver problemi ad interpretare.

Insomma, il caos non è detto debba vincere sempre.

Empatia, la grande amica del DevOp moderno.

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.

Tags: ,