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.
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
