modulo 02 / lezione 09

Lavorare in solitario: i comandi quotidiani

git log: leggere la storia di un progetto

Conoscere le opzioni di log che trasformano una lista piatta in una narrazione utile.

60 minGit e controllo versione

git log: leggere la storia di un progetto

git log non è solo una lista di commit. È uno strumento di indagine. Ti permette di capire quando è stato introdotto un comportamento, chi ha toccato una parte del codice, quale branch ha portato una modifica e come si è evoluta una decisione.

Saper leggere la storia è una competenza da manutentore, non un dettaglio da terminale.

Perché questa lezione conta

Quando erediti una codebase, il codice racconta lo stato attuale. La storia racconta il percorso. Spesso il “perché” di una scelta non è in un commento, ma in un commit, in una PR o in un cambio successivo.

git log ben usato riduce supposizioni. Prima di riscrivere un modulo, puoi capire da dove arriva. Prima di cancellare una condizione, puoi scoprire quale bug aveva risolto.

Obiettivo operativo

Alla fine della lezione devi saper usare git log per leggere il grafo, filtrare per file, autore, data e contenuto, e costruire un alias leggibile.

Vista grafica

Comando base utile:

git log --oneline --graph --decorate --all

Mostra:

  1. commit abbreviati;
  2. grafo dei branch;
  3. nomi di branch e tag;
  4. tutti i riferimenti visibili.

Alias consigliato:

git config --global alias.lg "log --graph --oneline --decorate --all"

Questo non sostituisce log, ma rende immediata la vista più utile.

Stat e patch

Per vedere impatto:

git log --stat

Per vedere anche il diff:

git log --patch

--patch è pesante su repo grandi. Usalo con filtri.

git log --patch -- src/auth.ts

Mostra solo la storia che tocca quel file.

Filtri per autore e data

git log --author="Carlo"
git log --since="2 weeks ago"
git log --until="2026-01-01"
git log --author="Carlo" --since="1 month ago" --oneline

Servono per capire attività, non per fare classifiche. La storia Git è contesto tecnico, non strumento di colpa.

Cercare contenuto: -S e -G

-S cerca commit che aggiungono o rimuovono una stringa:

git log -S "verifyEmail" --oneline

-G cerca commit il cui diff matcha una regex:

git log -G "timeout|retry" -- src/

Differenza pratica: -S è utile per seguire l’introduzione o rimozione di un simbolo. -G è utile per pattern più ampi nel diff.

Range di commit

git log main..feature/login

Mostra commit raggiungibili da feature/login ma non da main.

git log origin/main..HEAD

Mostra cosa hai localmente e non hai ancora pushato o integrato, a seconda del branch.

Questi range sono fondamentali prima di aprire PR o fare rebase.

Storia di una funzione

Per seguire l’evoluzione di una funzione puoi usare:

git log -L :nomeFunzione:src/file.ts

Non funziona sempre perfettamente in ogni linguaggio o stile, ma quando funziona è molto utile: mostra come quella funzione è cambiata commit dopo commit.

Laboratorio guidato

Scegli un repo reale e rispondi a queste domande usando solo git log:

  1. Quando è stato introdotto un file importante?
  2. Chi ha modificato per ultimo una funzione critica?
  3. Quali commit del tuo branch non sono su main?
  4. Quando è comparsa una stringa o opzione specifica?
  5. Quale commit ha rimosso una condizione?

Annota il comando usato per ogni risposta.

Output atteso

Un piccolo playbook:

Voglio vedere il grafo -> git lg
Voglio vedere storia di un file -> git log -- file
Voglio cercare quando appare una stringa -> git log -S
Voglio vedere commit non in main -> git log main..branch

Errori comuni

Usare solo git log senza opzioni. Su repo reali diventa subito poco leggibile.

Dimenticare --all. Potresti non vedere branch non correnti.

Cercare nel codice attuale quando serve cercare nella storia. rg trova oggi, git log -S trova quando.

Trattare blame/log come giudizio personale. Sono strumenti per capire decisioni.

Checklist di verifica

  • ho un alias grafico leggibile;
  • so filtrare log per file;
  • so usare -S per cercare introduzione/rimozione di una stringa;
  • so leggere un range main..branch;
  • so usare log prima di modificare codice storico.

Esercizi

Base · facile

Mostra la storia del progetto in forma compatta, un commit per riga.

Soluzione
git log --oneline
# a1b2c3d Aggiungi login
# e4f5g6h Correggi validazione

--oneline riduce ogni commit a hash breve + oggetto: ideale per avere una panoramica veloce senza scorrere pagine di dettagli.

Intermedio · medio

Visualizza la storia come grafo con branch e merge, e filtra i commit di un autore o per intervallo di date. Spiega quando serve il grafo.

Soluzione
git log --oneline --graph --decorate --all
git log --author="Anna" --since="2 weeks ago" --oneline

Il --graph disegna le linee dei branch e i punti di merge: indispensabile per capire la topologia (chi è derivato da cosa, dove si sono uniti i rami) che la lista lineare nasconde. I filtri (--author, --since) restringono la storia a ciò che cerchi.

Sfida · difficile

Usa git log per cercare quando una certa stringa di codice è stata introdotta o rimossa. Spiega la differenza con git blame.

Soluzione
git log -S "calcolaSconto" --oneline      # commit che aggiungono/tolgono quella stringa
git log -p -S "calcolaSconto"             # con il diff di ciascuno

-S (pickaxe) trova i commit in cui il numero di occorrenze di una stringa cambia: utile per scoprire quando una funzione è nata o sparita. git blame invece dice chi ha toccato per ultimo ogni riga attuale di un file: blame guarda lo stato presente riga per riga, log -S scava nella storia per un contenuto specifico.

Collegamenti

  • Modulo: Lavorare in solitario: i comandi quotidiani — lezione 9 del corso.
  • Torna nel modulo 7 con blame e bisect.