modulo 02 / lezione 08

Lavorare in solitario: i comandi quotidiani

git status e git diff: leggere prima di agire

Trasformare status e diff in abitudine prima di ogni commit per evitare sorprese.

60 minGit e controllo versione

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.

Esercizi

Base · facile

Usa git status per capire lo stato del repo e git diff per vedere le modifiche non ancora in stage.

Soluzione
git status   # cosa è staged, non-staged, untracked
git diff     # differenze working tree ↔ index (modifiche non in stage)

git status dà la mappa generale (in quali aree stanno le modifiche); git diff mostra il contenuto preciso dei cambiamenti non ancora messi in stage. Leggere prima di agire evita commit di cose sbagliate.

Intermedio · medio

Distingui git diff da git diff --staged. Crea una situazione in cui i due comandi mostrano cose diverse e spiegala.

Soluzione
echo "v1" >> f.txt; git add f.txt   # v1 in stage
echo "v2" >> f.txt                  # v2 non in stage
git diff            # mostra v2 (working tree ↔ index)
git diff --staged   # mostra v1 (index ↔ ultimo commit)

git diff confronta working tree e index: ciò che ancora non hai messo in stage. git diff --staged confronta index e ultimo commit: ciò che entrerà nel prossimo commit. Sono due confini diversi, e guardarli entrambi prima di committare evita sorprese.

Sfida · difficile

Usa le opzioni di git diff per confrontare due commit o due branch e per vedere solo i nomi dei file cambiati. Spiega un caso reale d’uso.

Soluzione
git diff main..feature              # differenze tra due branch
git diff HEAD~3 HEAD --stat         # riepilogo (file + righe) ultimi 3 commit
git diff --name-only main feature   # solo i nomi dei file cambiati

a..b confronta lo stato di due riferimenti; --stat dà un riepilogo sintetico; --name-only elenca solo i file. Caso reale: prima di aprire una pull request, git diff main..feature --stat ti fa vedere a colpo d’occhio l’ampiezza della modifica e se hai toccato file che non c’entrano.

Collegamenti

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