Git Bisect e Blame — Trovare il Commit che Ha Introdotto un Bug in 5 Minuti

Il bug è vivo, tu non sai quando è comparso. O peggio: sai che c'è da settimane, ma nessuno ricorda cosa è stato cambiato. Apri la history, scorri 200 commit a mano e perdi un'ora. Poi scopri che era una virgola in più in un file che non tocchi da tre mesi. Succede. A noi è successo. Ecco perché esistono due strumenti che ogni sviluppatore dovrebbe conoscere: git bisect e git blame. Non servono poteri magici. Servono due comandi e un po' di metodo. In questa guida ti spieghiamo come usarli per smettere di perdere tempo su bug che potevi risolvere in pochi minuti.

Cos'è Git Blame e Come Ti Aiuta a Trovare l'Ultima Modifica su una Riga di Codice?

Git blame è il tuo detective personale. Ti dice, per ogni riga di un file, chi l'ha modificata l'ultima volta, in quale commit e quando. Non ti dice perché il bug è stato introdotto, ma ti dà il punto di partenza esatto. Se il bug è su una riga specifica, blame ti mostra l'autore e il commit che ha toccato quella riga per ultimo. Attenzione: non sempre il commit incriminato è l'ultimo modificatore. A volte un bug nasce da una modifica precedente che ha creato una dipendenza rotta. Ma nella maggior parte dei casi, se il bug è localizzato in una riga, blame è la via più veloce.

Come Usare Git Blame in Pratica

# Mostra per ogni riga di index.php l'autore e il commit
git blame index.php

# Output tipico:
# a1b2c3d4 (Mario Rossi 2024-03-15 10:30:00 +0100 42) $prezzo = $costo * $margine;
# e5f6g7h8 (Luigi Bianchi 2024-03-14 09:15:00 +0100 43) $iva = $prezzo * 0.22;

Il codice sopra mostra: il commit hash (abbreviato), l'autore, la data, e la riga. Se su quella riga c'è un errore di calcolo, sai subito chi ha toccato quel punto e quando. Ma attenzione: se il bug è stato introdotto da una riga che non è stata modificata dopo, blame punterà a un commit ancora più vecchio. E se nessuno ha mai modificato quella riga? Allora il bug è lì dall'inizio del file. Blame ti dà comunque il commit di creazione.

Limitazioni di Git Blame

Blame funziona quando sai esattamente su quale riga si trova il bug. Ma se il bug è un comportamento anomalo che non è riconducibile a una singola riga? Oppure se il bug compare solo in un determinato scenario, come un errore di logica in una funzione? In quei casi, blame non basta. Serve git bisect.

Cos'è Git Bisect e Come Funziona la Ricerca Binaria sui Commit?

Git bisect implementa una ricerca binaria sulla cronologia dei commit. Invece di testare ogni commit uno per uno, divide a metà l'intervallo di commit sospetti e ti chiede: "in questo commit, il bug c'è o no?". Ogni risposta dimezza il numero di commit da controllare. Con 100 commit, bastano circa 7 passaggi. Con 1000, circa 10. È MOLTO più veloce di una ricerca lineare.

Quando Usare Git Bisect

Quando il bug è riproducibile e non sai quando è comparso. Esempio classico: un form di checkout smette di funzionare. Sai che funzionava la settimana scorsa. Oggi no. Non ricordi cosa hai cambiato. Con bisect, gli dici: "il commit di una settimana fa era buono, quello di oggi è cattivo". Lui ti guida attraverso i commit intermedi, ti chiede di testarli, e alla fine ti dice esattamente quale commit ha rotto tutto.

Come Eseguire Git Bisect Passo per Passo?

1. Avvia la Sessione di Bisect

# Supponiamo che il bug sia comparso nel commit HEAD (cattivo)
# e che il commit buono sia identificato dal tag v1.0
git bisect start
git bisect bad         # segna il commit corrente come cattivo (contiene il bug)
git bisect good v1.0   # segna v1.0 come buono (non conteneva il bug)

Git controlla fuori un commit a metà strada tra i due estremi. Ora devi testare quel commit.

2. Testa il Commit Corrente e Segna lo Stato

# Dopo aver verificato manualmente o con uno script automatico:
# se il bug è presente in questo commit:
git bisect bad

# se il bug non è presente:
git bisect good

# Git si sposta automaticamente al prossimo commit da testare.
# Ripeti fino a quando Git ti mostra il commit incriminato.

Alla fine Git stampa qualcosa come:

a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0 è il primo commit cattivo

E puoi vedere cosa è stato modificato in quel commit con:

git show a1b2c3d4

3. Automatizzare con un Test Script

Se hai un test automatizzato che riproduce il bug, puoi passarlo a bisect con l'opzione run:

git bisect start HEAD v1.0
git bisect run phpunit tests/CheckoutTest.php

Il comando esegue il test su ogni commit. Se il test fallisce (exit code diverso da 0), bisect lo segna come cattivo. Se passa, come buono. Alla fine ti dà il commit incriminato. Risparmi ore di manualità.

4. Termina la Sessione

git bisect reset

Riporta il repository allo stato originale. Non dimenticare questo passaggio, altrimenti rimani in modalità bisect.

Git Blame vs Git Bisect — Quale Strumento Usare in Quale Situazione?

Blame è per bug localizzati in una riga specifica. Bisect è per bug diffusi, comportamenti anomali, regressioni. Se non sai nemmeno in quale file cercare, bisect è la scelta giusta. Se sai la riga ma non il commit, blame ti dà la risposta in un comando. Spesso si usano insieme: prima bisect per trovare il commit, poi blame per capire esattamente cosa è stato modificato in quel commit su un file specifico.

Git Bisect e Blame in Team — Come Evitare Conflitti e Fraintendimenti?

In un team, blame può creare tensione se usato male. "Chi ha scritto questa schifezza?" è l'approccio sbagliato. Noi lo usiamo con una regola: blame serve a capire il contesto, non a incolpare. Un bug può essere stato introdotto da una modifica che sembrava innocua in un contesto diverso. Bisect invece è puramente tecnico: non c'è giudizio, solo ricerca. Noi lo integriamo spesso nei nostri workflow con script di CI che lo eseguono automaticamente su regressioni segnalate dai test. Così lo sviluppatore riceve direttamente il commit incriminato e può fixare senza perdere tempo a cercare.

Cosa Fare Adesso per Iniziare a Usare Git Bisect e Blame?

1. Prova blame su un file che conosci: apri il terminale nella tua repo, scrivi git blame nomefile e osserva l'output. Identifica una riga e verifica il commit corrispondente con git show.
2. Simula un bug per esercitarti con bisect: crea una repository di test, fai alcuni commit, poi introduci deliberatamente un bug in un commit intermedio. Usa bisect per trovarlo. Fallo prima manualmente, poi automatizza con uno script.
3. Integra bisect nel tuo flusso di debugging: la prossima volta che hai una regressione, invece di cercare a caso, parti subito con git bisect start. Cronometra quanto tempo risparmi.
4. Ricorda di resettare sempre: dopo ogni sessione bisect, esegui git bisect reset per tornare allo stato normale.

Noi, di Meteora Web, usiamo questi strumenti quotidianamente nei nostri progetti Laravel e WordPress. Quando un cliente ci segnala un'anomalia, non iniziamo a guardare il codice a caso. Avviamo bisect, troviamo il commit, e risolviamo in pochi minuti. Se vuoi approfondire il controllo versione e i workflow di team, leggi il nostro articolo principale: Git per Sviluppatori — Dalle Basi ai Workflow Team per Codice Senza Conflitti.