Una volta predisposta l’area di staging con le modifiche desiderate, è possibile procedere alla creazione di un commit. È importante ricordare che eventuali file ancora non aggiunti allo staging, ovvero quelli che sono stati creati o modificati ma per i quali non è stato eseguito il comando git add, non verranno inclusi nel commit corrente. Tali file rimarranno nello stato di modified nella working directory e potranno essere aggiunti successivamente.
Supponiamo, ad esempio, che l’ultimo comando git status abbia mostrato che tutte le modifiche risultano già correttamente inserite nello staging. In questo caso, è possibile eseguire il commit con il comando più semplice:
git commit
L’esecuzione del comando apre l’editor di testo configurato come predefinito (ad esempio Vim o Emacs), determinato dalla variabile d’ambiente EDITOR della shell. Tale editor può essere modificato a piacere tramite:
git config --global core.editor "<nome_editor>"
All’interno dell’editor viene mostrato un template che include:
- una riga vuota in cui inserire il messaggio di commit;
- un riepilogo delle modifiche in formato commentato, generato automaticamente da git status.
Le righe precedute dal carattere # sono considerate commenti e non vengono salvate nel commit. È possibile rimuoverle o lasciarle come promemoria.
 |
| FIG 1 - git commit |
Per avere un contesto ancora più dettagliato, è possibile utilizzare l’opzione -v:
git commit -v
 |
| FIG 2 - git commit -v |
In questo caso, oltre al riepilogo, viene mostrato anche il diff delle modifiche, consentendo di verificare con precisione quali linee di codice saranno incluse nel commit.
In alternativa, è possibile specificare il messaggio direttamente da riga di comando con l’opzione -m:
git commit -m "Modifica Projects1.cs"
Il messaggio deve essere chiaro, conciso e descrittivo, in modo da facilitare la comprensione della cronologia del progetto. È buona pratica adottare convenzioni uniformi all’interno del team di sviluppo (ad esempio includere ID di ticket o issue).
Output del commit
- il branch su cui è stato eseguito il commit (es. master o main);
- l’hash SHA-1 che identifica in maniera univoca il commit;
- il numero di file modificati;
- le statistiche sulle linee aggiunte e rimosse.
 |
| FIG 3 - Output commit |
Il commit come snapshot
È fondamentale sottolineare che un commit non registra semplicemente le differenze, ma rappresenta un vero e proprio snapshot dello stato del progetto nell’area di staging in quel momento. Tutti i file non inclusi nello staging rimarranno inalterati nella working directory e potranno essere oggetto di un commit successivo.
Ogni commit diventa così una tappa storica nel ciclo di vita del progetto, alla quale è possibile tornare in caso di necessità, oppure confrontarla con versioni più recenti per analizzare l’evoluzione del codice.
Best Practice per i Messaggi di Commit
Un commit efficace non riguarda solo il codice, ma anche la documentazione della modifica. Scrivere messaggi chiari e coerenti consente a chiunque (incluso il sé stesso futuro) di comprendere rapidamente la storia del progetto.
Ecco alcune linee guida ampiamente riconosciute:
1. Usare un titolo breve e descrittivo
- Limitare la prima riga a 50 caratteri circa.
- Utilizzare il modo imperativo (es. “Fix bug”, “Add feature”, “Refactor code”) per descrivere l’azione.
2. Aggiungere una descrizione più dettagliata se necessario
- Inserire una riga vuota dopo il titolo.
- Fornire ulteriori spiegazioni sul perché della modifica, non solo sul cosa è stato cambiato.
3. Fare commit atomici
- Ogni commit deve contenere una modifica logica unica e indipendente.
- Evitare commit che mescolano refactoring, correzioni e nuove funzionalità.
4. Riferirsi a ticket o issue
- Quando si lavora in team con strumenti come Jira, GitHub o GitLab, citare l’ID del ticket o il numero dell’issue. Ad esempio:
git commit -m "Fix #182: corregge l’errore di serializzazione JSON"
5. Seguire convenzioni standardizzate
- Molti team adottano lo schema dei Conventional Commits, che prevede prefissi come:
- feat: per nuove funzionalità
- fix: per bugfix
- docs: per modifiche alla documentazione
- refactor: per miglioramenti interni al codice
- test: per aggiunta o modifica di test
Esempio:
feat(auth): aggiunta autenticazione tramite OAuth2
6. Evitare messaggi generici
- Non usare commit come "update", "fix bug", "varie modifiche".
- Essere sempre specifici.
