Fare commit — cos'è, regole di formattazione e lavoro con Git

Cos'è un commit in Git

Un commit in Git è un oggetto che memorizza lo stato dei file di progetto in un determinato momento. Ogni commit contiene un'istantanea di tutti i file tracciati, un riferimento al commit padre e metadati. A differenza di altri sistemi di controllo versione, Git utilizza content-addressable storage — ogni oggetto è identificato da un hash SHA-1 del suo contenuto.

Quando uno sviluppatore fa commit delle modifiche, Git crea un oggetto commit che memorizza: un oggetto tree (struttura dei file), hash del commit padre, autore, committer, data e messaggio. Questo oggetto è immutabile — una volta creato, un commit non può essere modificato senza cambiare il suo hash. Questa immutabilità garantisce l'integrità della cronologia del progetto.

# Preparare le modifiche e fare commit
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# Visualizzare i dettagli del commit
git log --oneline -3
git show HEAD

# Preparare tutte le modifiche e fare commit in un unico passaggio
git commit -a -m "Update dependencies to latest versions"

I commit formano un grafo aciclico diretto (DAG), dove ogni nuovo commit fa riferimento al precedente. Ciò consente di navigare nella cronologia, annullare le modifiche e analizzare l'evoluzione del codebase. Comprendere la struttura del DAG di Git è la base per il lavoro avanzato con i commit.

Come fare commit delle modifiche correttamente

Il processo di commit in Git consiste in due fasi: aggiungere le modifiche all'area di staging (indice) e creare il commit. L'area di staging consente allo sviluppatore di selezionare quali modifiche specifiche includere nel commit, anche se molti file sono stati modificati nella directory di lavoro.

La regola dell'atomicità è il principio chiave di un buon commit. Ogni commit dovrebbe contenere una modifica logica. Se uno sviluppatore corregge un bug e refactoring del codice — questi dovrebbero essere due commit separati. I commit atomici semplificano la revisione del codice, il rollback delle modifiche e l'analisi della cronologia.

Prima di fare commit, vale la pena verificare: se nel codice sono rimasti output di debug, blocchi commentati o modifiche accidentali. Per questo si usa il comando git diff --cached, che mostra esattamente cosa sarà incluso nel commit. Un controllo aggiuntivo con git status visualizza l'elenco dei file nell'area di staging.

• Controlla le modifiche — git diff --cached mostra cosa sarà incluso nel commit
• Controlla la qualità — il codice deve superare il linter e i test prima del commit
• Scrivi un messaggio — una descrizione chiara dello scopo della modifica
• Verifica i file in staging — git status conferma l'elenco dei file

Regole per scrivere i messaggi di commit

Il messaggio di commit è la documentazione della modifica per gli sviluppatori futuri. Un buon messaggio risponde alle domande: cosa è stato modificato e perché. La convenzione Conventional Commits (team Angular, 2016) è diventata uno standard per molti progetti e definisce il formato: tipo(ambito): descrizione.

Un buon messaggio di commit consiste in un'intestazione (fino a 50 caratteri) e un corpo (opzionale, fino a 72 caratteri per riga). L'intestazione è scritta all'imperativo: “Add” non “Added” o “Adds”. Capitalization e punto alla fine dell'intestazione non vengono usati — è una convenzione internazionale di Git.

Un messaggio scadente: “fix things” o “update” — non fornisce informazioni. Tra un mese, uno sviluppatore non sarà in grado di capire cosa è stato esattamente modificato e perché. Un buon messaggio: “fix(payment): handle timeout in stripe callback” — è immediatamente chiaro cosa e dove è stato corretto.

Errori comuni quando si fa commit

Gli sviluppatori, specialmente i principianti, commettono spesso errori tipici quando fanno commit. Il più comune è un commit troppo grande, che mescola decine di modifiche. Tale commit non può essere parzialmente annullato e la revisione del codice diventa un supplizio.

Il secondo errore più frequente è un messaggio di commit scadente. Messaggi come “fix”, “update”, “changes” o “wip” non forniscono contesto agli sviluppatori futuri. Tra sei mesi, nessuno ricorderà cosa è stato esattamente corretto. La regola è semplice: immagina che tra un anno stai guardando la cronologia cercando di trovare una modifica specifica.

Il terzo errore è fare commit di codice non compilato o non funzionante. Dopo un commit, il codice deve almeno compilare. Non rompere la build è un requisito di base per qualsiasi commit in un ramo condiviso. Per questo, la build e i test vengono eseguiti prima del commit.

Il quarto errore è fare commit di dati riservati. Chiavi API, password e token non dovrebbero finire nella cronologia Git. Se un segreto è già stato commitato, non basta rimuoverlo in un nuovo commit, ma deve essere eliminato dall'intera cronologia tramite git filter-branch o BFG Repo-Cleaner.

Tecniche avanzate di lavoro con i commit

Git fornisce strumenti per gestire la cronologia dei commit. Uno dei più utili è git commit --amend, che permette di integrare l'ultimo commit con nuove modifiche o correggere il messaggio. È comodo se lo sviluppatore ha dimenticato di includere un file o ha fatto un errore di battitura nel messaggio.

# Correggere l'ultimo messaggio di commit
git commit --amend -m "fix(auth): correct token validation logic"

# Aggiungere file dimenticato all'ultimo commit
git add missed-file.txt
git commit --amend --no-edit

# Rebase interattivo per gli ultimi 3 commit
git rebase -i HEAD~3

Il rebase interattivo è un potente strumento per riscrivere la cronologia. Permette di combinare commit (squash), cambiare messaggi (reword), riordinare (reorder) ed eliminare commit (drop). Tuttavia, rebase modifica la cronologia, quindi viene usato solo su commit locali che non sono ancora stati inviati a un repository remoto.

Esistono due approcci per annullare i commit. git revert crea un nuovo commit che annulla le modifiche del precedente — un metodo sicuro che preserva la cronologia. git reset rimuove commit dalla cronologia — pericoloso se i commit sono già stati inviati. Nello sviluppo di team, solo git revert viene usato per annullare i commit pubblicati.