#howto - Guida all'utilizzo di git, parte 9: studiare la storia delle modifiche.
← Articolo precedente, parte 8: diff e patch
→ Articolo precedente, parte 9: bisect
Quando si parla di software di versioning, git
è sicuramente il primo programma che ci viene in mente. Rappresenta l’alternativa più diffusa a sistemi come svn
, utilizzata anche in ambito enterprise.
Rappresenta anche uno dei primi scogli che dipendenti alle prime armi affrontano in azienda.
Ecco quindi una guida passo passo a git, parte 9: studiare la storia delle modifiche.
Obiettivi
Questo articolo affronterà i seguenti argomenti:
- blame
- log
- reflog
- show
- grep
log
git log
rappresenta la storia dei commit del progetto. Ad ogni commit viene associato un codice SHA univoco che si può poi verificare tramite questo comando, inoltre viene mostrato:
- Username ed email dell’utente che ha fatto il commit
- Data
- Messaggio
- Branch (non in tutte le declinazioni di git log)
Nei vari articoli si sono visti alcuni esempi d’uso:
- Il log completo:
git log
. - Una versione in cui ogni log occupa una linea e gli SHA sono abbreviati (ma comunque sempre unici)
git log --oneline
- Una versione con un grafo git log –graph –color –decorate –oneline –all
Si analizzino meglio le varie opzioni:
--oneline
Visualizza i commit in una sola riga mostrando SHA abbreviato, prima riga del messaggio, branch.--graph
Mostra i commit utilizzando un grafo che evidenzia eventuali merge.--decorate
Mostra alcune informazioni aggiuntive come il branch e l’url di riferimento.--all
Mostra i commit da tutti i branch/origin--color
Un output colorato--follow
Non è stata vista in articoli precedenti. Questa opzione, se messa prima del nome di un file, mostra la storia dei commit per quello specifico file. A differenza digit log nomefile
segue la storia di quel file anche se viene rinominato o spostato
Blame
Letteralmente “colpa”, questo comando serve per mostrare, riga per riga, l’ultimo commit che ha modificato o creato quella riga. Insieme al commit son visualizzate informazioni su:
- Nome utente
- Nome del file (se cambiato nel tempo)
- Data della modifica
- Numero di riga
È molto utile per scoprire l’autore di alcune modifiche in modo da rintracciarlo e bruciargli il computer chiedere delucidazioni magari o chiarimenti.
La ricerca del colpevole
Tralasciando le battute sulle sorti di chi sporca il codice o introduce bug, ho citato scherzosamente git blame
in un altro articolo che parla della “ricerca del colpevole” nei vari team e delle conseguenze del tempo perso a cercare un agnello sacrificale più che in quello speso per la risoluzione del problema.
Qui il link per l’articolo pausacaffé nel quale ne parlo
reflog
Il reflog
, o ref-log
, è un log generico per il repository che tiene traccia delle sue modifiche strutturali (a livello di branch, merge, checkout, reset etc…)
Si usa semplicemente scrivendo:
git reflog nomeremote/nomebranch
Si può omettere sia il nome del remote (si prende il repository locale) che il nome del branch (nel caso viene preso il branch corrente).
grep
Questo comando ha la stessa funzione del classico grep
UNIX, ovvero quello di cercare le corrispondenze di una determinata stringa di ricerca tra i vari file del progetto. Si usa semplicemente scrivendo:
git grep "termine di ricerca"
Normalmente git grep
opera all’interno del proprio albero di working directory, è soggetto alle limitazioni imposte da git sulla lista dei file in cui deve cercare. Per fare un esempio concreto: non cerca in file ignorati da .gitignore.
Ci sono diverse opzioni utili, alcune di queste sono:
-n
Per mostrare i numeri di riga-G
Per utilizzare la sintassi delle regex-E
Per utilizzare la sintassi estesa delle regex-o
Mostra solo le parole che hanno un match-i
Ignora il case sensitive-v
Unverte il match (cerca le cose che non son richieste)--untracked
Mostra i risultati anche nei file non tracciati--recurse-submodules
Cerca nei sottomoduli git (ovvero progetti git innestati).
show
Il comando show
serve a mostrare tutte le informazioni riguardanti un commit. La sintassi è:
git show SHACOMMMIT
Dopo averlo eseguito si otterranno diverse informazioni come:
- Dati dell’utente che ha effettuato il commit, con la data ed il branch
- Messaggio di commit
- Il diff del commit
È un comando molto utile e spesso sottovalutato, ma con una funzionalità tanto banale quanto essenziale. Si può specificare un file di output eventualmente:
git show SHACOMMIT --output /percorso/file/log
Oppure salvarlo sotto forma di patch (stile format-patch
):
git show SHACOMMIT --patch --output /percorso/file.patch
Mostra terminale vuoto con –output
Eseguendo --output
quello che succede è che l’output viene salvato in un file, tuttavia git prova lo stesso a mostrare un risultato in una pagina less
(less è un programma che mostra il contenuto di un file riga per riga interattivamente).
Questo obbliga l’utente poi a chiudere questa “pagina vuota” del terminale con il tasto q
. Per evitare questo comportamento si può scrivere:
git config core.pager cat
Per tornare allo stato originale scrivere:
git config core.pager less