git status

Il comando git status risponde a una domanda semplice e costante mentre lavori: cosa è cambiato dall'ultimo commit e cosa è pronto per essere committato? È il comando che esegui più di ogni altro — prima dello staging, prima del commit, e ogni volta che perdi traccia dello stato di un file. Questa pagina spiega i tre stati in cui può trovarsi un file, come leggere l'output lungo e quello breve, e le opzioni che rendono status adatto agli script.

Cosa mostra git status

git status visualizza lo stato di due cose: la working directory (i file su disco che stai modificando) e la staging area, chiamata anche index (lo snapshot che stai preparando per il prossimo commit). Ti indica quali file sono:

• In staging — modifiche aggiunte con git add e pronte per il prossimo commit.
• Non in staging (modificati) — file tracciati che hai cambiato ma non ancora aggiunto.
• Non tracciati — nuovi file che Git non ha mai visto e non sta seguendo.

Ciò che git status non mostra è la cronologia dei commit. Non dice nulla sui commit precedenti, sui branch uniti o su chi ha cambiato cosa — per questo usa git log. Né mostra il contenuto delle modifiche; per vedere le righe esatte aggiunte e rimosse, usa git diff. In sintesi, status riassume l'effetto di git add e git commit sui file correnti.

Utilizzo di base

Il comando nella forma più comune non richiede argomenti:

git status

In un repository pulito senza nulla da fare, Git te lo comunica:

On branch master
nothing to commit, working tree clean

Lettura dell'output lungo

L'output predefinito (raggiungibile anche con --long) è il formato verboso e leggibile dall'utente. Segui un file nel suo ciclo di vita per vedere ogni sezione apparire.

Un file nuovo che Git non ha mai visto è non tracciato:

On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	w3docs.txt

nothing added to commit but untracked files present (use "git add" to track)

Dopo git add w3docs.txt, lo stesso file si sposta sotto Changes to be committed — è ora in staging:

On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   w3docs.txt

Una volta eseguito git commit, la working tree è di nuovo pulita. Ora modifica w3docs.txt e crea un secondo file new.txt. Un file tracciato che modifichi appare sotto Changes not staged for commit, mentre il file nuovo rimane sotto Untracked files:

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   w3docs.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	new.txt

no changes added to commit (use "git add" and/or "git commit -a")

Nota che i suggerimenti tra parentesi sono veri comandi eseguibili: Git ti indica come rimuovere dallo staging, ignorare le modifiche o aggiungere a ogni passaggio.

Il formato breve

Una volta compreso il significato delle sezioni, il formato lungo diventa ridondante. Il flag -s (o --short) condensa tutto in una riga per file:

git status -s

Per lo stato precedente (un file tracciato modificato, un nuovo file non tracciato) stampa:

 M w3docs.txt
?? new.txt

Ogni voce ha un codice di stato a due colonne. La colonna sinistra rappresenta la staging area (l'index) e la colonna destra la working tree:

Uno spazio iniziale significa "nessuna modifica in quella colonna." Quindi M significa modificato ma non in staging, M significa che la modifica è in staging, e MM significa una modifica in staging più ulteriori modifiche non in staging sullo stesso file.

Aggiungi -b per stampare anche il branch corrente e le informazioni di tracking:

git status -sb

## master
 M w3docs.txt
?? new.txt

Output per script: --porcelain

Se vuoi leggere git status da uno script, non analizzare il formato breve o lungo — entrambi possono cambiare tra le versioni di Git e sono influenzati dalla configurazione dell'utente. Usa invece --porcelain. Garantisce un formato stabile e leggibile dalle macchine:

git status --porcelain

 M w3docs.txt
?? new.txt

Le colonne sono gli stessi codici a due caratteri del formato breve, ma il formato è contrattualmente stabile, rendendolo sicuro per hook, controlli CI e prompt della shell. Abbinalo a -z per terminare ogni voce con un byte NUL invece di un newline, che mantiene non ambigui i nomi di file contenenti spazi o newline.

Visualizzare i file ignorati

Per impostazione predefinita git status nasconde i file corrispondenti alle regole del tuo .gitignore — artefatti di build e file binari come .pyc, .obj, .exe, o file di log altrimenti sommergherebbero le vere modifiche. Per confermare che un file viene ignorato (piuttosto che semplicemente dimenticato), aggiungi --ignored:

git status --ignored

Con un .gitignore contenente *.log e un debug.log su disco, appare una sezione aggiuntiva:

Ignored files:
  (use "git add -f <file>..." to include in what will be committed)
	debug.log

È il modo più rapido per eseguire il debug di una regola di ignore che corrisponde a più — o meno — di quanto atteso.

Opzioni comuni

Perché controllare lo status spesso

È buona pratica eseguire git status prima di ogni git add e git commit. Un rapido controllo intercetta gli errori comuni: committare un file dimenticato nello staging, mettere accidentalmente in staging un file di debug, o committare sul branch sbagliato. Poiché status legge soltanto il repository senza modificare nulla, eseguirlo è sempre sicuro.

Una volta letto lo status, i passi naturali successivi sono ispezionare le modifiche esatte con git diff, annullare un errore di staging con git reset, oppure, se non hai ancora iniziato, creare il repository con git init.

Esercitazione