La timeline del file: guarda ogni file evolversi commit dopo commit

La domanda che ogni sviluppatore prima o poi si pone

Il mese scorso funzionava. Ne sei sicuro. La sidebar era allineata, il parser delle date gestiva i fusi orari, il pulsante aveva la giusta tonalità di blu. Poi arriva una segnalazione di bug, e ora ti ritrovi a fissare un file con due anni di storia, cercando di rispondere a una domanda solo in apparenza semplice: quando è cambiato questo, e quale commit ne è responsabile?

Subito dietro arriva la seconda domanda: chi ha fatto quella modifica, e perché? Il messaggio del commit potrebbe spiegarlo. L'autore potrebbe ricordarselo. Ma prima devi trovare il commit, ed è lì che inizia la ginnastica mentale.

La cassetta degli attrezzi della CLI, e dove non basta

Git ha già tutto ciò che serve per indagare la storia di un file. Gli strumenti sono potenti e collaudati -- l'attrito non sta in nessun singolo comando, ma in quanti ne devi concatenare.

git log --follow

git log --follow --oneline -- src/styles/sidebar.css

Questo elenca ogni commit che ha toccato il file, anche attraverso le rinomine. È il punto di partenza giusto. Ma ti restituisce SHA e messaggi di commit, non contenuti. Per vedere come appariva davvero il file in un dato momento, ti serve il comando successivo.

git show SHA:path

git show a3b4c5d:src/styles/sidebar.css

Questo stampa il file completo così com'era a quel commit. Per confrontare due versioni, lo esegui due volte e fai il diff dell'output, oppure usi git diff a3b4c5d 9f2e1d0 -- src/styles/sidebar.css. Ora ripeti l'operazione per ogni commit candidato. Se trenta commit hanno toccato il file, passerai un bel po' di tempo a copia-incollare SHA, tenendo a mente per tutto il tempo le differenze tra le versioni.

git blame

git blame src/styles/sidebar.css

Blame annota ogni riga con l'ultimo commit che l'ha modificata. È eccellente quando la riga sospetta è ancora nel file e vuoi sapere chi l'ha scritta. È meno utile quando la regressione viene da una riga che è stata eliminata, o quando la modifica più recente a una riga è un'innocua riformattazione che nasconde la modifica che ti interessa davvero. A quel punto ti ritrovi a lanciare git blame SHA^ -- path più e più volte, sfogliando la storia uno strato alla volta.

git bisect

Bisect esegue una ricerca binaria su tutta la tua storia per trovare il commit che ha rotto un comportamento testabile. Quando "rotto" significa che la build fallisce o un test diventa rosso, bisect è esattamente lo strumento giusto, e niente in una GUI lo sostituisce. Ma è macchinario pesante per una domanda come "quando è cambiata questa regola CSS?". Non hai bisogno di fare checkout e ricompilare il progetto a ogni passo -- vuoi solo guardare un file nel tempo.

Quindi la risposta della CLI a "guarda questo file evolversi" è: elenca i commit con log, stampa ogni versione con show, fai il diff delle coppie a mano, e tieni tutto lo stato nella tua testa. Ogni comando funziona. Il problema è il workflow.

La timeline del file: una risposta visuale

GitSquid ha introdotto la timeline del file nella v2.6, ed è inclusa nel piano Free. L'idea è semplice: invece di ricostruire mentalmente l'evoluzione di un file commit dopo commit, la guardi accadere sullo schermo.

Aprila con un clic destro

Fai clic destro su un file qualsiasi e scegli Mostra cronologia. Si apre la vista della cronologia del file, concentrata interamente su quel singolo file.

Una tacca per ogni commit

Una striscia temporale si trova sopra il visualizzatore del file: una tacca per ogni commit che ha toccato il file. L'intera vita del file, disposta in orizzontale. Un file con tre commit appare tranquillo; un file con sessanta tacche ti dice qualcosa sul suo churn prima ancora di aver letto una sola riga.

Scorri tra le versioni

Trascina lo slider e il visualizzatore si aggiorna mentre trascini. Questo è il cuore della funzionalità: non stai saltando tra snapshot discreti di cui devi fare il diff mentalmente -- stai guardando il file cambiare. Lo scrubbing avanti e indietro risulta istantaneo dopo la prima passata, quindi una volta attraversata la storia una volta, puoi oscillare liberamente intorno a una zona sospetta, restringendo il campo fino al commit esatto in cui le cose sono cambiate.

Passa il mouse per vedere chi ha cambiato cosa

Passa il mouse su una tacca qualsiasi e ottieni l'autore e le informazioni del commit per quel punto della storia. La domanda "chi l'ha scritto e quando" trova risposta senza lasciare la timeline, e senza lanciare blame.

Premi play

Fai clic su ▶ e GitSquid riproduce automaticamente la storia. Per una prima passata su un file sconosciuto, è il modo più rapido per costruirsi un'intuizione: vedi le strutture apparire, crescere, venire rifattorizzate. È la differenza tra leggere trenta diff e guardare un time-lapse.

Snapshot o Diff

Un interruttore Snapshot / Diff nell'intestazione alterna tra due viste: il contenuto completo del file così com'era a quel commit, oppure il classico diff file-contro-genitore. La modalità Snapshot risponde a "che aspetto aveva il file allora?"; la modalità Diff risponde a "che cosa ha cambiato esattamente questo commit?". La caccia alle regressioni di solito inizia in modalità Snapshot e finisce in modalità Diff.

Salta a una versione

Una volta trovata la versione che ti interessa, tre azioni sulla destra ti portano oltre: Copia SHA mette l'hash del commit nei tuoi appunti per usarlo ovunque, Apri commit salta al commit completo così puoi vedere cos'altro è cambiato insieme al tuo file, e Checkout detached porta la tua working directory esattamente a quel commit quando hai bisogno di eseguire davvero il vecchio codice.

Caso pratico: trovare una regressione CSS

Un esempio concreto. La sidebar della tua app ha perso il suo padding, e nessuno sa quando. Ecco la caccia con la timeline del file:

1. Clic destro su sidebar.css → Mostra cronologia. La timeline mostra 24 tacche distribuite su otto mesi.
2. Scorri dal più recente al più vecchio tenendo d'occhio la regola del padding. Verso i due terzi, la regola cambia visibilmente. Dopo la prima passata, lo scrubbing è istantaneo, quindi muovi lo slider avanti e indietro intorno a quella zona finché non isoli la tacca esatta in cui il valore è cambiato.
3. Passa il mouse sulla tacca. È stato un collega, tre settimane fa, in un commit etichettato come refactoring del layout. Mistero risolto a metà.
4. Passa a Diff. L'interruttore mostra il diff file-contro-genitore: il padding è stato compresso in una proprietà shorthand, e un valore si è perso per strada. Eccola, la regressione.
5. Apri commit. Il commit completo rivela che ha toccato dodici file come parte di un intervento più ampio -- il genere di modifica facile da revisionare con poca attenzione. Se nel tuo team si discute di come modifiche del genere debbano finire nella storia in primo luogo, vedi rebase vs merge.
6. Copia lo SHA e correggi. Con il commit colpevole identificato, puoi fare revert, correggere in avanti, o fare cherry-pick aggirandolo -- la nostra guida su come annullare un commit Git spiega quale opzione si adatta a quale situazione.

Tempo totale: un paio di minuti, nessuno SHA memorizzato, nessuna archeologia nello scrollback del terminale.

Quando blame o bisect resta lo strumento giusto

La timeline non sostituisce il resto della cassetta degli attrezzi, e fingere il contrario sarebbe disonesto:

• Usa blame quando stai già guardando una riga specifica e vuoi il suo ultimo autore lì sul posto. Per una singola riga che non è stata riformattata di recente, blame resta la via più breve.
• Usa bisect quando il sintomo è "la build si è rotta" o "un test fallisce" e non sai quale file ne sia responsabile. Bisect cerca nella storia dell'intero repository; la timeline esamina un solo file. Rispondono a domande diverse.
• Usa la timeline quando la domanda riguarda l'evoluzione di un singolo file: quando è cambiato, chi l'ha cambiato, e che aspetto aveva prima.

Guarda il tuo codice evolversi

La timeline del file è inclusa nel piano Free di GitSquid -- nessun account, nessuna telemetria, nativa su macOS, Windows e Linux. Apri un repository, fai clic destro su un file su cui ti sei sempre fatto domande, e premi play.

Scarica GitSquid Free e regala alla tua prossima caccia alla regressione una timeline invece di una lista di SHA.