git status e git diff: leggere prima di agire

git status e git diff sono i due comandi che dovrebbero precedere quasi ogni azione importante. Prima di staged, prima di commit, prima di pull, prima di reset: guarda lo stato reale.

Molti disastri Git non nascono da comandi complessi. Nascono da comandi semplici lanciati senza leggere cosa c’era nel working tree.

Perché questa lezione conta

Git ti dà sempre segnali. Il problema è abituarsi a leggerli. git status non dice solo quali file sono cambiati: dice branch corrente, rapporto con upstream, file staged, file non staged, file untracked e suggerimenti sui comandi.

git diff ti mostra la sostanza. È la review personale prima della review del team.

Obiettivo operativo

Alla fine della lezione devi saper leggere status e diff in modo sistematico, distinguere working tree e stage, e scegliere il diff giusto per la domanda giusta.

Leggere git status

Versione completa:

git status

Versione compatta:

git status -sb

Esempio:

## feature/login...origin/feature/login [ahead 2]
 M src/auth.ts
A  src/session.ts
?? debug.log

Significa:

1. sei su feature/login;
2. hai 2 commit locali non pushati;
3. src/auth.ts è modificato ma non staged;
4. src/session.ts è staged come nuovo file;
5. debug.log è untracked.

Questo è già un controllo qualità.

I tre diff fondamentali

git diff

Working tree vs index: cosa hai modificato ma non staged.

git diff --staged

Index vs HEAD: cosa finirà nel prossimo commit.

git diff HEAD

Working tree completo vs ultimo commit: staged e non staged insieme.

Prima del commit, il comando più importante è:

git diff --staged

Perché mostra esattamente il commit futuro.

Diff leggibili

Alcune opzioni aiutano:

git diff --stat
git diff --name-only
git diff --word-diff
git diff -- src/auth.ts

--stat dà una vista di impatto. --name-only è utile per controllare scope. --word-diff aiuta su Markdown, testo e stringhe lunghe. Il path limita la vista a un file o directory.

Per spostamenti e rinomine:

git diff --find-renames

Prima di agire

Routine sicura:

git status -sb
git diff
git diff --staged

Prima di un reset:

git status -sb
git diff > /tmp/wip.patch

Non è obbligatorio salvare sempre patch, ma quando stai per usare un comando distruttivo, avere una copia temporanea può salvarti.

Cosa cercare nel diff

Durante la lettura chiediti:

1. Ci sono file non correlati?
2. Ci sono debug log o commenti temporanei?
3. Ci sono segreti, token o dati locali?
4. Il diff contiene solo una intenzione?
5. Ci sono formattazioni massive che nascondono la logica?
6. I test o documenti necessari sono inclusi?

Questa è una code review minima fatta da te prima di chiedere tempo agli altri.

Laboratorio guidato

Prendi un tuo repo e crea intenzionalmente:

1. una modifica corretta;
2. un file temporaneo;
3. una modifica non correlata;
4. un file staged;
5. un file non staged.

Senza guardare l’editor, usa solo git status e git diff per ricostruire la situazione. Poi pulisci fino a ottenere uno stage coerente.

Output atteso

Una checklist pre-commit:

1. git status -sb
2. git diff
3. git diff --staged
4. niente file temporanei
5. niente modifiche fuori scope
6. messaggio coerente col diff staged

Errori comuni

Guardare solo l’elenco file. Un file corretto può contenere una riga sbagliata.

Dimenticare gli untracked. git diff non mostra file non tracciati.

Leggere il diff sbagliato. git diff non mostra cosa è già staged.

Nascondere modifiche logiche dentro formattazione. Se formatti, fallo in commit separato.

Checklist di verifica

• so interpretare git status -sb;
• so scegliere tra git diff, git diff --staged e git diff HEAD;
• controllo file untracked prima del commit;
• so limitare un diff a file o directory;
• leggo lo stage prima di committare.

Collegamenti

• Modulo: Lavorare in solitario: i comandi quotidiani — lezione 8 del corso.
• Questa routine prepara restore/reset della lezione 10.