Il comando git blame in Git

Il comando git blame è uno strumento estremamente utile che ci aiuta a vedere l’autore delle modifiche di una linea di codice. Il comando è molto utile per analizzare uno specifico punto nella cronologia e per chi è l’autore della modifica.

L’estensione Gitlens per Visual Studio Code, piuttosto che piattaforme online come Github e Bitbucket permettono di visualizzare l’output di blame senza dover eseguire effettivamente il comando da terminale.

Ma cosa possiamo fare effettivamente con questo comando? Beh la traduzione letterale di blame è “incolpare”, ciò significa che ci aiuta a capire chi ha modificato una specifica riga del codice.

Mettiamo alla prova git blame

Per poter vedere in azione git blame abbiamo bisogno di un file con un po’ di storia e nel nostro caso, se hai seguito le lezioni precedenti, il file che è stato oggetto del maggior numero di commit è ciao.txt.

Quindi possiamo eseguire il comando:

1$ git blame ciao.txt

Blame ha sempre bisogno di un file, non può essere eseguito senza niente come abbiamo visto per altri comandi. L’output del comando, nel mio caso è il seguente:

1^937db31 (Manuel Ricci 2023-06-07 12:59:06 +0200 1) Ciao, sono Manuel
214b02a5a (Manuel Ricci 2023-06-07 12:59:58 +0200 2) Hello there!
399bb4c6a (Manuel Ricci 2023-06-07 13:08:40 +0200 3) Hola, soy Manuel
4bdc5f468 (Manuel Ricci 2023-06-07 13:11:22 +0200 4)
5bdc5f468 (Manuel Ricci 2023-06-07 13:11:22 +0200 5) Dai un occhio al file lorem.txt

Ogni linea riporta

• hash
• autore
• timestamp
• riga
• contenuto

In questo caso specifico l’autore è uno solo, ma in altri casi potrebbe essere anche più ricco in termini di partecipanti.

1 82496ea3 (kevzettler     2018-02-28 13:37:02 -0800  1) # Git Blame example
282496ea3 (kevzettler     2018-02-28 13:37:02 -0800  2)
389feb84d (Albert So      2018-03-01 00:54:03 +0000  3) This repository is an example of a project with multiple contributors making commits.
482496ea3 (kevzettler     2018-02-28 13:37:02 -0800  4)
582496ea3 (kevzettler     2018-02-28 13:37:02 -0800  5) The repo use used elsewhere to demonstrate `git blame`
682496ea3 (kevzettler     2018-02-28 13:37:02 -0800  6)
789feb84d (Albert So      2018-03-01 00:54:03 +0000  7) Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod TEMPOR incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
889feb84d (Albert So      2018-03-01 00:54:03 +0000  8)
9eb06faed (Juni Mukherjee 2018-03-01 19:53:23 +0000  9) Annotates each line in the given file with information from the revision which last modified the line. Optionally, start annotating from the given revision.
10eb06faed (Juni Mukherjee 2018-03-01 19:53:23 +0000 10)
11548dabed (Juni Mukherjee 2018-03-01 19:55:15 +0000 11) Creating a line to support documentation needs for git blame.
12548dabed (Juni Mukherjee 2018-03-01 19:55:15 +0000 12)
13548dabed (Juni Mukherjee 2018-03-01 19:55:15 +0000 13) Also, it is important to have a few of these commits to clearly reflect the who, the what and the when. This will help Kev get good screenshots when he runs the git blame on this README.

Questo è il risultato di git blame su una repository open source il cui scopo è proprio quello di testare git blame.

In questo caso l’output presenta tre autori. Considerando che git blame server per “incolpare” l’autore è importantissimo come anche il timestamp e il contenuto della modifica (insomma, praticamente tutto).

Le varie flag del comando git blame

Come anche altri comandi visti in passato, anche git blame non è esonerato dalle flag. Anzi ne ha alcune decisamente interessanti, come:

• -L <range>: serve a mostrare le informazioni solo per uno specifico range di righe.
• -e: serve a visualizzare l’email dell’autore al posto del nome e cognome
• -w: permette di ignorare le modifiche relative al cambiamento delle spaziature. Capita molto spesso di formattare il file dopo che è stato salvato e quindi di rifare la commit solo per aver messo a posto gli spazi, ecco in questo caso queste genere di modifiche viene ignorata.
• -C: individua le linee che sono state spostate o copiate da altri file. In questo caso verrà mostrato l’autore originale invece di chi ha fatto lo spostamento o il copia e incolla.

Qual è la differenza tra git blame e git log?

Per quanto ad un primo colpo d’occhio potrebbe sembrare che git blame e git log siano simili, in realtà dovete tenere a mente che git blame mostra l’ultimo autore che ha modificato una determinata riga, se l’esigenza è quella di capire chi, per primo, ha inserito una riga di codice, allora in quel caso git log è più indicato.

Se fossimo interessati a sapere in quali commit la riga di codice ha subito dei cambiamenti, ricordate git blame ci mostra solo l’ultimo autore della modifica, possiamo sempre eseguire il comando git log accompagnato dalla flag -S, in questo modo:

1$ git log -S”Hello there”
2commit 14b02a5a742ef49d9b82e0305c16f16c555c4e61
3Author: Manuel Ricci <manuel@webtea.it>
4Date:   Wed Jun 7 12:59:58 2023 +0200
5
6    Seconda commit

In questo caso non ho fatto nessuna modifica alla riga dopo il primo salvataggio, quindi la voce nel log sarà univoca.

Conclusione

git blame è quindi uno strumento molto utile quando si tratta di capire chi ha fatto una modifica e quando. Molti strumenti online o estensione dei code editor offrono una visione di git blame integrata nella User Interface, quindi più comoda da analizzare rispetto all’output nel terminale.

Nella prossima lezione vediamo più nel dettaglio il comando git merge, eh sì è giunto il momento di unificare le branch.