Episodio Pilota: introduzione a Git

Git è uno strumento incredibile, ma come tutti gli strumenti, diventa davvero potente solo se impari ad usarlo bene.
Mi è capitato spesso di vedere utilizzare Git come un mero mezzo di condivisione codice con altri, incurante di come venissero raggruppate le modifiche ed etichettate tramite commit. Lo scopo principale per molti è ancora buttare il codice in remoto alla rinfusa cosicché altri possano usarlo.
Il che non è del tutto sbagliato, ma Git è molto più di questo.
Se sei solito usare Git per lo più in modo superficiale, sono certa che potrai trarre benefici da questa serie di post dedicata all'argomento.
Cominciamo col definire alcune buone pratiche per gestire un repository.

Quando dovrei usare uno strumento di controllo di versione?

Non importa che la tua sia un'azienda remota o meno, non importa nemmeno se lavori solo o in gruppo. Come dice il nome stesso, è uno strumento di controllo di versione, non di persone in remoto. Pertanto la risposta corretta a questa domanda è "sempre". A meno che tu non stia realizzando una paginetta al volo da buttare su un server e non toccare mai più, sono piuttosto certa che tenere traccia delle modifiche nel tempo al tuo progetto ti tornerà utile. D'altronde, come vedremo, Git può essere usato tranquillamente anche soltanto in locale, senza necessariamente creare un repository in remoto. Per cui non ci sono buone ragioni per non usarlo. 🙂

Come scrivere messaggi di commit significativi

La prima indiscutibile regola è che i commit devono essere scritti in inglese, non importa quale sia la tua lingua madre. Perché? Per la stessa ragione per cui i linguaggi di programmazione sono scritti in inglese: è la lingua franca comprensibile da tutti perché diventata standard a livello mondiale. Non puoi asserire con certezza che non lavorerai mai con persone straniere che parlano una lingua diversa dalla tua, perciò immagina se ad un certo punto, fosse anche per un breve periodo di tempo, ti trovassi a dover lavorare con altre persone, tutte da paesi diversi: se ognuno di loro scrivesse commit nella loro lingua madre, che babilonia sarebbe?

Se ci pensi non è così inusuale: stai sviluppando un progetto ed ad un certo punto decidi di renderlo open source. Il gioco è fatto: ora il tuo repository è potenzialmente esposto ad un pubblico mondiale. Scrivere in inglese fin dall'inizio rende il tuo repository comprensibile da tutti per sempre, indipendentemente dai piani iniziali che hai per il tuo progetto.

Un'altra buona pratica è di definire e mantenere uno stile specifico nella stesura dei commit. Questo non solo crea una cronologia più pulita, la rende molto utile. Se hai una lista legata al progetto in cui tieni traccia delle attività da fare (backlog), usala per marcare i messaggi dei commit con gli ID univoci di tali attività. Con quale stile lo decidi tu:

• [BACKLOG-XXX] <messaggio>

• ref. #BACKLOG-XXX <messaggio>

• BACKLOG-XXX - <messaggio>

Non c'è un modo corretto. Aderisci ad uno stile e mantienilo.

Un altro stile che potresti voler provare è quello suggerito dai Commit Convenzionali, molto valido poiché aiuta anche a definire che tipo di modifica un particolare commit contiene.

Riguardo la porzione relativa al messaggio del commit, è buona regola utilizzare la forma imperativa come se fosse un comando che spiega cosa dovrebbe fare il codice se l'HEAD del repository fosse puntato a quello specifico hash di commit. Perciò, per esempio, diciamo che hai appena terminato di scrivere un nuovo componente che all'interno del tuo progetto rappresenta una card di prodotto; invece di creare il commit con questo testo "added a product card" (in inglese, ricordi?), potresti scrivere: "create a product card". Nota che il verbo è in forma imperativa. Puntare ad uno specifico commit che chiede di fare qualcosa diventa così più significativo se ti devi muovere avanti e indietro nella storia.

A parte i messaggi, suggerisco di raggruppare le modifiche ai file riguardanti una funzione specifica sotto lo stesso messaggio di commit. Quindi, se, ad esempio, hai modificato un file per cambiare il titolo della pagina e hai anche creato un nuovo componente nello stesso ramo, queste due attività dovrebbero essere divise in due commit diversi con il proprio specifico "messaggio di commit sotto forma di comando".
Riporterò nei prossimi episodi degli esempi più pratici e chiari di ciò che intendo.

Vedremo anche, più avanti, come si possono unire solo alcune delle modifiche fatte ai file, ancora in lavorazione, sotto lo stesso commit semantico senza troppi mal di testa. Come già detto, è utile mantenere commit separati per ogni attività in modo semantico per diversi motivi, due dei quali sono l'annullamento delle modifiche e la selezione specifica di alcune modifiche (cherrypick), che vedremo anch'essi prossimamente in dettaglio.

Ultimo, ma non meno importante, anzi forse proprio il più importante, i commit devono contenere sempre un messaggio. Banale, ma non è così inusuale ritrovarsi nella storia commit senza messaggi o con il messaggio di default <no message> che è assolutamente inutile.

Il messaggio del commit non dovrebbe essere né troppo corto né troppo lungo. Per scrivere un messaggio che sia utile, pensa di scrivere una nota al te stesso del futuro riguardo a ciò che il codice di quei file specifici fa, usando parole chiavi indicative che potresti voler usare per ricercare questa modifica. Aiuta davvero, soprattutto se ad un certo punto ti ritroverai realmente a dover cercare proprio questo commit.

Perciò ricordati sempre di scrivere i messaggi dei tuoi commit seguendo i consigli di cui sopra.

Un repo pulito, assieme a commit informativi ed un buon uso dei branch, diventerà uno strumento molto potente e utile nel tuo lavoro quotidiano di cui non potrai più fare a meno.

Ed eccoci qua! Con questi consigli alla mano, sei pronto per iniziare un fantastico viaggio all'interno di Git e del suo flusso!

Strumenti essenziali

Prima di addentrarci, raccomando caldamente di scaricare GitKraken, che ti fornirà una mappa visuale di come il tuo repo è gestito. Illustrerò ogni step attraverso questo strumento che ti aiuterà a seguire e capire meglio il tutto. Naturalmente, tutte le cose si possono fare tramite riga di comando, ma alcune potrebbero essere davvero difficili da comprendere senza uno schema visivo.
Vedremo anche come Github e Gitlab ti permettono di fare direttamente in remoto alcune delle cose che approfondiremo.