Salvare i file nella Git Directory con git commit

Una volta “promossi” i file della working directory nella staging area è giunto il momento di salvare quanto fatto.

Perché come menzionato in precedenza git add non salva i file, ma è commit il responsabile del salvataggio nel database di versionamento.

Per salvare uno snapshot delle modifiche in staging viene usato il comando:

1$ git commit -m <messaggio>

git add e git commit sono i due comandi più utilizzati in assoluto (insieme forse a git status, che vedremo più avanti).

Come funziona la commit di git dietro le quinte?

Git possiamo immaginarlo come una linea del tempo dove le commit sono le date importanti da ricordare. La commit cattura lo stato del progetto in un preciso punto nel tempo.

Rispetto a sistemi centralizzati come SVN, Git non forza l’interazione con il server fino a quando non siamo pronti.

Mentre la staging area è considerabile come uno spazio tra la working directory e la repository locale, la repository locale è uno spazio tra i nostri contributi e la repository centrale.

Tutta la questione di staging area e repository locale è fantastica perché permette di lavorare in un ambiente isolato, integrandosi con la code base principale solo quando sarà necessario.

Sono però vantaggi del singolo individuo, in ottica di collaborazione ricordate sempre che le integrazioni devono essere frequenti e in piccole unità.

Ci sono numerose best practice che si possono adottare a proposito, ma di base questa è la regola principe per una collaborazione sana con l’intero team.

Snapshot non differenze: le performance di Git

Più volte è stato ribadito e affermato che Git, rispetto agli altri è più performante, ma perché?

Prendiamo in considerazione ancora una volta SVN, una commit per questo sistema di versionamento consiste in una serie di differenze tra il file originale e quello salvato nella repository.

Git dal canto suo registra l’intero contenuto di ogni file ad ogni commit. Questo rende le operazioni più veloci, perché non deve mettere insieme le varie modifiche. Il concetto di snapshot è importantissimo per Git, perché influenza ogni suo processo.

Flag interessanti

Anche commit è un comando dalle flag interessanti, quelle che bisogna sapere sono:

• -a: permette di aggiungere tutte le modifiche della working directory fatte ai file modificati (non untracked), bypassando git add.
• -m “messaggio”: permette di scrivere un messaggio che ci permetterà di capire cosa è stato fatto (un fix ad un particolare bug, correzione di un typo, ecc.)
• -am “messaggio”: combinazione dei due flag precedenti
• --amend: se ci siamo dimenticati un file dopo aver fatto una commit possiamo inserirlo nella commit successiva che non ne creerà una nuova, ma modificherà la precedente
• --no-edit: insieme ad --amend evita la modifica del messaggio della precedente commit.

Senza messaggio Git aprirà l’editor dove dovrete scriverlo per finalizzare la commit.

Un buon messaggio di commit

Prendiamoci del tempo per parlare un attimo della qualità dei messaggi di commit. Perché nella maggior parte dei casi sono così:

Se xkcd ci ha fatto una vignetta allora vuol dire che è vero.

Un messaggio di commit è estremamente importante perché permette ad altri sviluppatori del team di capire cosa è stato fatto e, ammettiamolo, serve anche a noi per capire cosa abbiamo fatto e se scriviamo cose incomprensibili o facciamo una commit che includono 1300 modifiche il cui messaggio è “varie modifiche”, beh allora rimarrà per sempre un segreto che solo l’universo conosce.

Per scrivere un buon messaggio di commit ci sono poche semplici regole:

• Non terminate con il punto
• Usate l’imperativo nell’oggetto (es. Aggiunta correzione al testo del pulsante)
• Specificate il tipo di commit (es. Fix, Update, Refactor, Chore, ecc.)
• La lunghezza ideale dell’oggetto è di 50 caratteri, mentre per il corpo si consiglia di andare a capo ogni 72 caratteri.
• Siate diretti eliminando parole filler (es. penso, forse, tipo, ecc.).
• Nel corpo spiega cosa e perché non come.

I punti possono variare in base con chi parlate e di idee per un template su misura ce ne sono tante, come:

• Come scrivere un messaggio di commit di Chris Beams (quello che mi ha ispirato maggiormente)
• Conventional commit (una specifica che mi ha influenzato, ma meno di Chris)
• Matt Summer con il suo semplicissimo template
• Alex Wasik con il suo template (un po’ più completo rispetto a Matt e più vicino a quello di Chris)
• C’è anche questo gist che si basa su ciò che scrive Chris

Poi alla fine si può fare un po’ come lo schema a zonzo di Diego Abatantuono, ognuno fa quel cazzo che gli pare.

Se non sai cosa scrivere e fidati che succede, puoi aiutarti con queste domande:

• Perché ho fatto questa modifica?
• Quali sono gli effetti della modifica?
• Perché c’era bisogno della modifica?
• A cosa fa riferimento questa modifica?

Come usare un template di un messaggio di commit

Hai scritto il tuo template o ne hai trovato uno online che vuoi assolutamente usare, ma devo tenermi un blocco note da qualche parte con il modello? No. Possiamo fare in modo che Git se lo peschi da solo quando vogliamo scrivere un messaggio di commit più ricco (nel 80% dei casi basta anche solo l’oggetto).

Per dire a Git di usare un template per un messaggio di commit dobbiamo ricorrere ad un comando che abbiamo già visto, git config.

• Create un file in una directory del vostro sistema (meglio se quella del proprio utente e magari in una cartella dedicata) chiamato .gitmessage
• Aprire il file in un editor e scopiazzare o scrivere il template che volete usare
• Salvate
• Indicare a Git il modello con il comando: $ git config --global commit.template <path>/.gitmessage
• Fatto

Conclusioni

Prossimo comando git status, per avere chiaro il quadro della situazione quando i file e le modifiche cominciano ad essere tanti.