Comandi Git essenziali: quelli che usi davvero ogni giorno

Git ha oltre centocinquanta comandi. Nella pratica quotidiana se ne usano circa dieci, e con altri cinque si risolvono quasi tutte le situazioni impreviste. In questo articolo trovi quelli che contano davvero, il flusso in cui si incastrano, e cosa fare quando qualcosa va storto — che è la parte in cui ci si blocca.

I tre stati dei file

Prima dei comandi serve capire una cosa, perché senza questa metà dei comandi sembrano arbitrari.

Un file modificato attraversa tre stati:

Modificato  →  In stage  →  Committato
(hai        →  (l'hai      →  (è nella
 cambiato)     marcato)       storia)

Lo stato intermedio — l'area di stage — è la particolarità di Git rispetto ad altri sistemi. Serve a scegliere cosa entra nel prossimo commit: puoi aver modificato cinque file e committarne solo due, tenendo gli altri per un commit separato.

Sembra un passaggio in più, ed è invece ciò che permette di costruire una storia pulita invece di ammassare tutto insieme.

Il flusso quotidiano

Questi sono i comandi che userai il 90% delle volte.

git status            # cosa è cambiato e in che stato
git add file.js       # metti in stage un file
git add .             # metti in stage tutto
git commit -m "..."   # salva nella storia
git push              # invia al server condiviso
git pull              # prendi le modifiche degli altri

git status è il comando più importante di tutti. Non modifica niente, ti dice dove sei e cosa sta succedendo. Nel dubbio, sempre quello: risolve la maggior parte dei momenti di confusione.

Sui messaggi di commit vale la pena spendere trenta secondi in più. "fix" e "aggiornamenti" non dicono nulla; "corregge il calcolo IVA sugli ordini esteri" ti salva tra sei mesi. È l'unica documentazione che non diventa obsoleta.

Rami

git branch                    # elenca i rami
git switch -c nuova-funzione  # crea un ramo e ci passa
git switch main               # torna al principale
git merge nuova-funzione      # unisce quel ramo in quello attuale
git branch -d nuova-funzione  # elimina il ramo

switch e restore sono i comandi moderni, introdotti per separare due funzioni che prima erano entrambe dentro checkout — con la confusione che ne derivava. Trovi ancora checkout ovunque nelle guide e continua a funzionare, ma per lavori nuovi conviene abituarsi ai nuovi.

Il flusso tipico: crei un ramo per una funzionalità, ci lavori, la unisci al principale quando è pronta. Il ragionamento completo è in cos'è il version control.

Guardare la storia

git log --oneline -10      # ultimi 10 commit, una riga ciascuno
git log --graph --oneline  # con la struttura dei rami
git diff                   # cosa ho modificato e non ancora messo in stage
git diff --staged          # cosa sto per committare
git show abc123            # dettaglio di un commit specifico
git blame file.js          # chi ha scritto ogni riga e quando

git diff --staged prima di ogni commit è un'abitudine che ripaga: ti mostra esattamente cosa stai per salvare, ed è il modo più efficace per non committare per sbaglio una chiave API o del codice di prova lasciato lì.

git blame ha un nome infelice — non serve a trovare colpevoli, ma a risalire al commit che ha introdotto una riga e leggerne la motivazione.

Annullare gli errori

Questa è la parte che serve davvero, perché è dove ci si blocca.

Ho modificato un file e voglio buttare le modifiche:

git restore file.js

Ho messo in stage per sbaglio:

git restore --staged file.js

Il messaggio di commit è sbagliato (e non l'ho ancora inviato):

git commit --amend -m "messaggio corretto"

Voglio annullare l'ultimo commit ma tenere le modifiche:

git reset --soft HEAD~1

Voglio annullare un commit già inviato agli altri:

git revert abc123

Quest'ultima distinzione è importante. revert crea un nuovo commit che annulla il precedente, lasciando la storia intatta. È l'unica opzione sicura quando il commit è già stato condiviso — perché riscrivere una storia che altri hanno già scaricato crea problemi a tutti.

Ho fatto un disastro e voglio tornare indietro:

git reflog        # elenca TUTTO quello che hai fatto
git reset --hard abc123

git reflog è la rete di sicurezza che quasi nessuno conosce. Registra ogni spostamento fatto nel repository locale, anche commit "persi". Se hai combinato un guaio con un reset, quasi sempre da lì si recupera. Prima di dare qualcosa per perso, guarda il reflog.

Mettere da parte il lavoro

git stash            # metti via le modifiche in corso
git stash pop        # riprendile
git stash list       # vedi cosa hai messo da parte

Serve quando stai lavorando a qualcosa e arriva un'urgenza su un altro ramo: metti via, cambi ramo, risolvi, torni e riprendi.

Attenzione: è facile dimenticarsene. Un git stash list ogni tanto evita di ritrovare lavoro di tre settimane fa che si credeva perso.

Lavorare con il server condiviso

git clone <url>              # scarica un repository
git remote -v                # vedi i server collegati
git fetch                    # scarica le novità SENZA applicarle
git pull                     # scarica E unisce
git push -u origin ramo      # invia un ramo nuovo

La differenza tra fetch e pull conta: fetch ti fa vedere cosa è cambiato senza toccare il tuo lavoro, pull scarica e unisce subito. Su progetti condivisi, fetch seguito da uno sguardo alla situazione è più prudente.

I comandi da usare con prudenza

git reset --hard — butta via le modifiche non committate senza chiedere conferma. Non si recuperano dal reflog, perché non erano mai state salvate.

git push --force — riscrive la storia sul server. Su un ramo condiviso può cancellare il lavoro degli altri. Se proprio serve, esiste --force-with-lease, che rifiuta l'operazione se qualcuno ha inviato modifiche nel frattempo.

git clean -fd — elimina i file non tracciati. Utile per fare pulizia, definitivo.

La regola pratica: prima di un comando distruttivo, fai git status e verifica dove sei. Trenta secondi che evitano ore.

Configurazione iniziale

Da fare una volta sola:

git config --global user.name "Nome Cognome"
git config --global user.email "tua@email.it"
git config --global init.defaultBranch main

Gli alias per i comandi che digiti di continuo sono uno di quegli accorgimenti a costo zero che ripagano ogni giorno, come gli altri raccolti in migliori tool di produttività per developer:

git config --global alias.st status
git config --global alias.lg "log --oneline --graph -15"

In sintesi

I comandi che servono ogni giorno sono pochi: status, add, commit, push, pull, più i comandi dei rami. Tutto il resto si impara quando serve.

Il concetto che rende comprensibile il resto è l'area di stage: lo stato intermedio che ti permette di scegliere cosa entra in un commit invece di salvare tutto insieme.

Per gli errori, le due cose da ricordare: revert se il commit è già stato condiviso (non riscrive la storia), e reflog prima di dare per perso qualcosa — è la rete di sicurezza che recupera quasi tutto.

E l'abitudine con il ritorno più alto: git status nel dubbio, git diff --staged prima di ogni commit.

Se stai partendo da zero con Git e GitHub, la guida introduttiva è come usare Git e GitHub.