Git Commit: La Guida Definitiva

Cos’è Git

Git è un sistema di controllo versione distribuito creato da Linus Torvalds nel 2005. È come una macchina del tempo per il tuo codice: ti permette di salvare lo stato del tuo progetto in diversi momenti e tornare a qualsiasi punto quando necessario. Al centro di questo sistema c’è il concetto di “commit”. Su questo blog ho trattato Git e Github in una guida dedicata.

Cos’è un commit

Un commit in Git è essenzialmente un’istantanea del tuo progetto in un determinato momento. Immagina di scattare una foto di tutti i tuoi file così come sono ora, aggiungere una nota che descrive cosa è cambiato, e conservare il tutto in un album ben organizzato. Questo è esattamente ciò che fa un commit.

Per chi è nuovo a Git, può sembrare complicato all’inizio, ma in realtà il concetto base è semplice: stai dicendo a Git “voglio ricordare come stanno le cose in questo momento”. Con il tempo e la pratica, diventerà un’abitudine naturale e un potente strumento nel tuo arsenale di sviluppo.

Questa guida ti accompagnerà nel mondo dei commit Git, partendo dai concetti fondamentali fino alle strategie avanzate. Che tu sia uno sviluppatore alle prime armi o un veterano in cerca di perfezionamento, troverai informazioni preziose per migliorare il tuo flusso di lavoro con Git.

Proprietà fondamentali

Permanente: Una volta creato, un commit non può essere modificato senza lasciare tracce
Atomico: Rappresenta un’unità logica completa di lavoro
Tracciabile: Ogni commit ha un identificativo unico (hash SHA-1)
Locale: Un commit avviene prima localmente e solo successivamente può essere condiviso

Permanenza: L’Inchiostro Indelebile della Storia del Codice

Quando crei un commit in Git, stai essenzialmente scrivendo un capitolo nella storia del tuo progetto con inchiostro indelebile. Questa permanenza è una caratteristica fondamentale che garantisce l’integrità e l’affidabilità dell’intero sistema.

Una volta che un commit è stato creato e condiviso con altri, non può essere cancellato o modificato senza lasciare tracce evidenti. Certo, esistono comandi come git rebase o git commit --amend che permettono di “riscrivere la storia”, ma questi creano in realtà nuovi commit con nuovi identificativi, lasciando testimonianza del cambiamento. È come cercare di modificare una pagina di un libro già pubblicato – puoi pubblicare una nuova edizione, ma chi possiede la vecchia edizione saprà che qualcosa è cambiato.

Questa proprietà è fondamentale per la collaborazione: assicura che tutti possano fidarsi della storia del progetto e che i cambiamenti non svaniscano misteriosamente.

Atomicità: L’Unità Indivisibile di Lavoro

Un commit ben fatto è come un atomo nel senso originale greco della parola: indivisibile. Rappresenta un’unità logica completa di lavoro che ha un senso compiuto in sé stessa.

Quando segui questo principio, ogni commit implementa una singola funzionalità, risolve un bug specifico, o apporta un cambiamento coerente al progetto. Non mescola diverse modifiche non correlate. È come un capitolo ben scritto in un libro che affronta un tema specifico prima di passare al successivo.

L’atomicità rende la storia del progetto comprensibile e facilita operazioni come il debugging, il code review, e l’eventuale necessità di annullare specifiche modifiche senza influenzare altre parti del codice.

Tracciabilità: L’Impronta Digitale Unica

Ogni commit in Git possiede un identificativo unico generato attraverso l’algoritmo SHA-1. Questo hash di 40 caratteri (come “a1b2c3d4e5f6…”) funziona come un’impronta digitale che identifica in modo univoco quel preciso commit e il suo contenuto.

Grazie a questa proprietà, puoi riferiti con precisione assoluta a qualsiasi punto nella storia del tuo progetto. È come avere coordinate GPS esatte per ogni tappa di un viaggio. Se qualcuno menziona “il commit 7d8e9f…”, entrambi sapete esattamente di quale modifica state parlando, senza possibilità di confusione.

Questa tracciabilità è particolarmente preziosa in progetti con molti collaboratori, dove permette di tenere traccia di chi ha fatto cosa e quando, creando un senso di responsabilità e facilitando la comunicazione.

Località: Prima Casa, Poi Mondo

Una delle caratteristiche più potenti di Git è la sua natura distribuita, e i commit ne sono il cuore. Quando crei un commit, questo avviene prima di tutto sul tuo computer locale, indipendentemente da qualsiasi connessione a internet o server remoto.

Questa località iniziale ti dà una libertà straordinaria: puoi lavorare offline, creare numerosi commit, sperimentare liberamente senza preoccuparti di interferire con il lavoro degli altri. È come scrivere nel tuo diario personale prima di decidere quali parti condividere pubblicamente.

Solo quando sei pronto, con un comando git push, condividi i tuoi commit con altri, pubblicandoli nel repository remoto. Questa separazione tra azione locale e condivisione globale ti permette di lavorare al tuo ritmo e di presentare il tuo lavoro solo quando lo ritieni completo e pronto per gli occhi altrui.

Insieme, queste quattro proprietà fondamentali rendono i commit Git non solo un meccanismo tecnico per salvare modifiche, ma un vero e proprio sistema di narrazione collaborativa che preserva la storia del progetto in modo affidabile, chiaro e flessibile.

Differenza tra commit e altri concetti

Commit vs Save: Salvare un file registra solo lo stato attuale; un commit registra i cambiamenti con contesto e metadati
Commit vs Push: Il commit è locale, il push invia i commit al repository remoto
Commit vs Sync: Sync è un’operazione che combina commit, push e pull

Il comando “Commit”

L’opzione “Commit” salva solo le modifiche localmente nel tuo repository Git. Quando selezioni questa opzione:

I file che hai messo in staging (quelli con il segno di spunta in VSC) verranno salvati in un nuovo snapshot del progetto
Viene creato un punto nella storia del tuo repository con un ID univoco (hash SHA-1)
Le modifiche rimangono solo sul tuo computer
Nessuna comunicazione avviene con il repository remoto
Il messaggio che hai inserito nella casella di testo sopra verrà usato come messaggio di commit

Il comando “Commit (Amend)”

Quest’opzione ti permette di modificare l’ultimo commit invece di crearne uno nuovo:

Unisce le modifiche attuali con l’ultimo commit fatto
Puoi correggere errori o aggiungere file dimenticati
Il messaggio di commit può essere modificato o mantenuto
L’hash del commit cambia, quindi è come creare un nuovo commit che sostituisce il precedente
Da usare solo per commit locali che non sono stati ancora condivisi (pushati)

Il comando “Commit & Push”

Questa opzione combina due operazioni in una singola azione:

Esegue un commit delle modifiche localmente (come l’opzione “Commit”)
Immediatamente dopo invia (push) i cambiamenti al repository remoto (GitHub, GitLab, ecc.)

Vantaggi:

Le modifiche diventano subito disponibili per gli altri collaboratori
Aggiorna la versione remota (“ufficiale”) del progetto
Risparmia tempo rispetto all’esecuzione separata di commit e push

Il comando “Commit & Sync”

Questa è l’opzione più completa che esegue tre operazioni:

Fa un commit delle modifiche locali
Invia (push) le tue modifiche al repository remoto
Scarica (pull) eventuali modifiche fatte da altri nel repository remoto

Vantaggi:

Assicura che il tuo repository sia aggiornato con tutte le modifiche recenti
Previene potenziali conflitti dovuti a modifiche parallele
Ottimo quando lavori in team dove più persone modificano lo stesso codice

Cosa usare?

Se vuoi solo registrare le modifiche localmente: usa “Commit”
Se hai commesso un errore nell’ultimo commit: usa “Commit (Amend)”
Se vuoi rendere le modifiche visibili ad altri: usa “Commit & Push”
Se vuoi anche ottenere gli ultimi aggiornamenti: usa “Commit & Sync”

Anatomia di un commit

Ogni commit Git contiene:

Hash: Identificativo univoco SHA-1 (es. a1b2c3d4e5...)
Autore: Nome e email dell’autore del commit
Data e ora: Timestamp di quando è stato creato
Messaggio di commit: Descrizione del cambiamento
Puntatore al commit genitore: Reference al commit precedente
Snapshot del progetto: Lo stato di tutti i file tracciati

Esempio di visualizzazione di un commit:

commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9
Author: Mario Rossi <mario.rossi@example.com>
Date:   Mon Apr 4 12:34:56 2025 +0200

    Fix bug nella funzione di login

    - Risolto il problema di validazione dell'input
    - Aggiunta sanitizzazione per prevenire SQL injection
    - Migliorata la gestione degli errori

Il Flusso di Lavoro Git: Un Viaggio in Quattro Tappe

Il flusso di lavoro Git può essere visto come un viaggio che i tuoi cambiamenti al codice intraprendono attraverso quattro aree distinte:

Working Directory: È dove inizi, lavorando direttamente sui file del tuo progetto. Qui scrivi codice, crei nuovi file, modifichi quelli esistenti, ed elimini ciò che non serve più. Git monitora queste modifiche ma non le registra ancora ufficialmente. È il tuo spazio di lavoro quotidiano, dove sperimenti e sviluppi.

Staging Area (o Index): Quando sei soddisfatto di alcune modifiche, le sposti qui con git add. Questa area intermedia ti permette di selezionare con precisione quali cambiamenti includere nel prossimo commit. Puoi continuare a lavorare su altri file mentre questi attendono di essere committati. È essenzialmente la “sala d’attesa” per le modifiche che ritieni pronte.

Repository Locale: Con git commit, le modifiche nella staging area vengono registrate permanentemente nella cronologia del tuo repository locale. Ogni commit è una fotografia completa del progetto in quel momento, con un messaggio che spiega le modifiche. Tutti questi commit formano la storia del progetto, ma esistono ancora solo sul tuo computer.

Repository Remoto: Quando esegui git push, condividi i tuoi commit con gli altri inviandoli al repository remoto (su GitHub, GitLab, ecc.). Solo a questo punto i tuoi cambiamenti diventano visibili agli altri membri del team. Analogamente, con git pull o git fetch, scarichi i commit che altri hanno pubblicato nel repository remoto.

Questa struttura a quattro livelli offre un controllo granulare sul processo di sviluppo, permettendoti di lavorare in modo indipendente ma coordinato con il resto del team.

[Working Directory] -> git add -> [Staging Area] -> git commit -> [Local Repo] -> git push -> [Remote Repo]

Stati dei file

In Git, ogni file nel tuo progetto passa attraverso diversi stati che ne rappresentano il ciclo di vita. Comprendere questi stati è fondamentale per utilizzare Git in modo efficace. Il sistema traccia costantemente lo stato di ogni file, permettendoti di sapere esattamente quali modifiche verranno incluse nel prossimo commit.

Untracked: File non ancora tracciati da Git. I file untracked sono quelli che esistono nella tua directory di lavoro ma che Git non “conosce” ancora. Quando crei un nuovo file nel tuo progetto, questo inizia nel stato untracked.
Modified: File tracciati che sono stati modificati. Un file è in stato “modified” quando è già tracciato da Git (è stato precedentemente committato) ed è stato modificato rispetto all’ultima versione salvata nel repository.
Staged: File modificati pronti per essere committati. I file in stato “staged” sono quelli che hai marcato per essere inclusi nel prossimo commit. Sono stati aggiunti all’area di staging (o “index”), una zona intermedia tra il tuo spazio di lavoro e il repository.
Committed: File salvati nel repository locale. I file “committed” sono quelli le cui modifiche sono state salvate permanentemente nella cronologia del repository locale.

Un file in Git passa tipicamente attraverso questo ciclo:

Untracked → Staged → Committed → Modified → Staged → Committed → ...

Visualizzazione degli Stati

Git fornisce diversi comandi per visualizzare lo stato dei file:

git status: Mostra una panoramica completa di tutti gli stati dei file
git diff: Mostra le modifiche non staged rispetto all'ultimo commit
git diff --staged: Mostra le modifiche staged che entreranno nel prossimo commit
git ls-files: Elenca tutti i file tracciati

Comprendere questi stati è essenziale per avere il pieno controllo sul processo di sviluppo e per gestire efficacemente le modifiche al tuo progetto.

Comandi base per il commit

Preparazione al commit

Prima di immortalare le tue modifiche in un commit, è fondamentale preparare adeguatamente il terreno. Questa fase preliminare è come organizzare gli ingredienti prima di cucinare un piatto elaborato. Inizia controllando lo stato del tuo repository con git status – questo comando ti mostrerà una fotografia completa della situazione attuale: quali file sono stati modificati, quali sono nuovi e quali sono pronti per essere committati.

La magia avviene con il comando git add, che ti permette di selezionare con precisione quali modifiche includere nel prossimo commit. Puoi aggiungere singoli file, intere cartelle, o tutto in una volta. È come scegliere quali foto inserire in un album – non devi necessariamente includerle tutte, ma solo quelle che raccontano una storia coerente.

Prima di finalizzare, è sempre buona pratica dare un’occhiata a cosa stai per committare con git diff –staged. Questo ti permette di rivedere le modifiche e assicurarti che tutto sia in ordine, come un ultimo controllo prima di spedire una lettera importante.

# Verificare lo stato dei file
git status

# Aggiungere file alla staging area
git add nomefile.txt          # Aggiunge un singolo file
git add cartella/             # Aggiunge una cartella
git add .                     # Aggiunge tutti i file modificati
git add -p                    # Aggiunge in modo interattivo (patch)

# Rimuovere file dalla staging area
git reset HEAD nomefile.txt

# Verificare le modifiche
git diff                      # Differenze tra working directory e staging
git diff --staged             # Differenze tra staging e ultimo commit

Esecuzione del commit

Una volta che hai preparato il palcoscenico, è il momento di eseguire il commit vero e proprio. Il comando git commit crea un punto fermo nella cronologia del progetto, un momento cristallizzato al quale potrai sempre tornare.

Il messaggio di commit è la tua opportunità di comunicare il “perché” dietro le modifiche. Può essere breve e conciso con l’opzione -m “Messaggio”, oppure più elaborato e strutturato se usi semplicemente git commit, che aprirà un editor di testo. Un buon messaggio di commit è come una buona didascalia per una fotografia – offre contesto e significato.

Se ti accorgi di aver dimenticato qualcosa, non preoccuparti: git commit –amend ti permette di modificare l’ultimo commit, aggiungendo file o correggendo il messaggio, come un post-scriptum a una lettera già scritta.

# Commit base
git commit                    # Apre l'editor per inserire il messaggio

# Commit con messaggio inline
git commit -m "Messaggio del commit"

# Commit con messaggio titolo e corpo
git commit -m "Titolo del commit" -m "Corpo del messaggio con più dettagli"

# Commit tutti i file modificati (salta git add)
git commit -a -m "Messaggio del commit"

# Modificare l'ultimo commit
git commit --amend            # Modifica l'ultimo commit

Commit avanzati

Andando oltre le basi, entriamo nel territorio dei commit avanzati. Qui troverai strumenti più sofisticati per gestire situazioni complesse.

Commit selettivi e interattivi

I commit selettivi ti permettono di essere chirurgicamente preciso. Con git add -p o git commit -p, Git ti guida attraverso ogni “blocco” di modifiche, chiedendoti se includerlo o meno. È come un editor che ti aiuta a raffinare il tuo testo, riga per riga.

Questo approccio è particolarmente utile quando hai fatto molte modifiche correlate a diversi aspetti del progetto ma vuoi creare commit separati per ciascun aspetto. Ti permette di mantenere una cronologia pulita e facilmente comprensibile, come capitoli ben definiti in un libro.

# Commit interattivo
git add -i                    # Modalità interattiva completa

# Commit di parti specifiche di file
git add -p                    # Aggiunge in modo interattivo
git commit -p                 # Commit di parti specifiche

# Commit di file specifici
git commit nomefile1.txt nomefile2.txt -m "Messaggio"

Retroattività e Manipolazione

Git offre anche strumenti per riscrivere la storia. Con git rebase -i, puoi riorganizzare, combinare o dividere commit passati. È come avere una macchina del tempo che ti permette di tornare indietro e riordinare eventi passati.

Ad esempio, potresti voler unire (squash) diversi commit correlati in uno solo per rendere la cronologia più leggibile, o dividere un commit troppo grande in parti più gestibili. Ricorda però che riscrivere la storia condivisa può creare confusione, quindi è meglio limitare queste operazioni ai commit non ancora condivisi con altri.

Retroattività e manipolazione

# Modificare l'ultimo commit
git commit --amend -m "Nuovo messaggio"    # Modifica messaggio
git commit --amend --no-edit               # Mantiene messaggio ma aggiunge nuovi file staged

# Unire più commit (squash)
git rebase -i HEAD~3                       # Modalità interattiva per gli ultimi 3 commit

# Dividere un commit
git rebase -i HEAD~3                       # Marca commit con "edit"
# Dopo rebase:
git reset HEAD^                            # Annulla commit mantenendo modifiche
git add -p                                 # Aggiungi selettivamente
git commit -m "Primo commit parziale"     
# ... ripeti per altre parti
git rebase --continue                      # Completa il rebase

Firmare i commit

La sicurezza è importante, e Git ti permette di firmare digitalmente i tuoi commit con GPG usando git commit -S. Questa pratica aggiunge un livello di autenticazione, garantendo che il commit provenga effettivamente da te. È come sigillare una lettera con il tuo sigillo personale – offre garanzia di autenticità.

Le firme digitali sono particolarmente importanti nei progetti open source o in ambienti aziendali dove la provenienza del codice deve essere verificabile.

# Firmare commit con GPG
git commit -S -m "Commit firmato"

# Verificare commit firmati
git log --show-signature

Commit vuoti e speciali

A volte, hai bisogno di creare un commit senza modificare alcun file. I commit vuoti (git commit --allow-empty) possono essere utili per attivare pipeline CI/CD o segnare punti importanti nella cronologia senza modificare il codice.

I commit di merge, d’altra parte, rappresentano la fusione di due linee di sviluppo. Con git merge --no-ff, puoi assicurarti che venga sempre creato un commit di merge, anche quando non sarebbe strettamente necessario, mantenendo visibile nella cronologia l’esistenza di un branch.

# Commit vuoto (utile per trigger CI/CD)
git commit --allow-empty -m "Trigger pipeline"

# Commit di merge
git merge branch-name                      # Crea un commit di merge automatico
git merge --no-ff branch-name              # Forza sempre un commit di merge

Strategie di commit efficaci

Messaggi di commit efficaci

Struttura ideale di un messaggio:

<tipo>(<scope>): <titolo breve>
<corpo del messaggio>
<footer>

Esempio:

fix(auth): corregge validazione token JWT

- Risolve il problema di scadenza token non correttamente verificata
- Aggiunge controllo firma con chiave pubblica
- Migliora gestione errori con messaggi più specifici

Closes #123

L’Arte dei Messaggi di Commit: Una Guida alle Convenzioni

Quando lavori con Git, i messaggi di commit sono la tua voce nella storia del progetto. Non sono semplici note, ma una forma di comunicazione con i tuoi collaboratori presenti e futuri, incluso il te stesso del futuro che probabilmente avrà dimenticato i dettagli di ciò che stavi facendo.

Le convenzioni per i messaggi di commit, in particolare quelle ispirate ai “Conventional Commits”, offrono un linguaggio comune e strutturato che rende immediatamente chiaro lo scopo di ogni modifica. È come avere un codice condiviso che tutti possono comprendere a colpo d’occhio.

Il Prefisso come Chiave di Lettura

Iniziare un messaggio di commit con un prefisso standardizzato è come apporre un’etichetta a un contenitore – permette di capire cosa c’è dentro senza doverlo aprire.

Quando usi feat: all’inizio del tuo messaggio, stai dichiarando con orgoglio: “Ecco qualcosa di nuovo che arricchisce il progetto!” Potrebbe essere una nuova funzione, un nuovo componente, o qualsiasi elemento che aggiunge valore per l’utente finale. Ad esempio: feat(auth): aggiunta autenticazione con Google.

Il prefisso fix: segnala una riparazione, come un meccanico che annuncia di aver risolto un problema nel motore. Indica agli altri sviluppatori che questa modifica corregge un bug o un comportamento indesiderato. Un esempio potrebbe essere: fix(carrello): risolto errore nel calcolo dello sconto.

Con docs:, comunichi che stai migliorando la documentazione – quel prezioso materiale che aiuta tutti a comprendere e utilizzare il codice. Questo prefisso è come dire: “Ho aggiunto delle indicazioni stradali più chiare”. Esempio: docs(API): aggiornata documentazione degli endpoint di pagamento.

Il prefisso style: riguarda l’aspetto e non la sostanza – è il parrucchiere del codice. Si riferisce a modifiche che non alterano il comportamento del codice ma lo rendono più elegante: indentazione, spazi, punti e virgola. Esempio: style(header): allineato codice alle linee guida del team.

Quando usi refactor:, stai dicendo che hai riorganizzato i mobili nella stanza senza cambiarne la funzione. Il codice fa le stesse cose di prima, ma in modo più efficiente, più chiaro o più manutenibile. Un esempio: refactor(database): semplificata logica di connessione.

Il prefisso test: indica che stai rafforzando la rete di sicurezza del progetto. Stai aggiungendo o modificando test che verificano il corretto funzionamento del codice. Esempio: test(validazione): aggiunti test per input email non validi.

Infine, chore: è per quei lavori di manutenzione necessari ma poco glamour. Come fare il bucato o pulire la casa, queste attività non aggiungono funzionalità immediate ma mantengono il progetto in salute nel lungo termine. Esempio: chore(dipendenze): aggiornate librerie di terze parti.

Il Valore della Coerenza

Adottare queste convenzioni crea un ritmo prevedibile nella storia del progetto. Leggere i log di commit diventa più semplice, come sfogliare un libro ben organizzato. Inoltre, queste convenzioni facilitano la generazione automatica di changelog e l’analisi della storia del progetto.

Quando tutto il team segue lo stesso pattern, si crea un linguaggio comune che rafforza la collaborazione. È come avere un vocabolario condiviso che tutti comprendono naturalmente.

Tipi comuni (ispirato a Conventional Commits):

feat: Nuova funzionalità
fix: Correzione bug
docs: Modifiche alla documentazione
style: Modifiche di formattazione
refactor: Riscrittura del codice senza cambiamenti funzionali
test: Aggiunta o modifica di test
chore: Modifiche al processo di build o strumenti ausiliari

Il Ritmo dei Commit: Dimensione e Frequenza

La filosofia dietro la gestione dei commit in Git è simile a quella di un buon racconto: dovrebbe essere diviso in capitoli chiari, coerenti e di lunghezza gestibile. Vediamo come dimensione e frequenza dei commit influenzano la qualità del tuo repository.

L’Eleganza dei Commit Atomici

I commit atomici sono come i mattoni ben tagliati di un edificio – ciascuno ha uno scopo preciso e si incastra perfettamente con gli altri. Quando ogni commit rappresenta un singolo cambiamento logico, crei una storia del progetto che è facile da comprendere, navigare e, se necessario, modificare.

Immagina di dover trovare il momento esatto in cui è stato introdotto un bug. Con commit atomici, puoi identificare precisamente quel cambiamento senza dover setacciare enormi blocchi di codice che mescolano molte modifiche diverse. È come cercare un libro specifico in una libreria ben organizzata invece che in un mucchio disordinato.

Inoltre, i commit atomici facilitano operazioni come cherry-pick (applicare una specifica modifica a un altro branch) o revert (annullare una modifica specifica). È molto più semplice estrarre o annullare una modifica pulita e autonoma che cercare di districare un groviglio di cambiamenti interconnessi.

Il Valore dei Commit Frequenti

Commettere frequentemente è come fare backup regolari del tuo lavoro – ti protegge dalla perdita di progressi e crea più punti di ritorno. Avere tanti piccoli commit invece di pochi grandi offre una granularità più fine nella storia del progetto.

Pensa ai commit come a punti di salvataggio in un videogioco. Preferiresti avere un singolo salvataggio dopo ore di gioco, rischiando di perdere tutto in caso di problemi, o salvataggi frequenti che ti permettono di tornare a vari momenti del tuo progresso?

I commit frequenti hanno anche un valore psicologico: ogni commit completato dà un senso di progresso e realizzazione. È più gratificante vedere una serie di piccoli obiettivi raggiunti che lavorare per ore senza un checkpoint visibile.

La Necessità di Commit Funzionanti

Un principio fondamentale è che ogni commit dovrebbe lasciare il codice in uno stato funzionante. È come fermarsi durante un viaggio solo in luoghi sicuri e accoglienti, non a metà di un ponte pericolante.

Quando ogni commit mantiene il codice in uno stato funzionante, qualsiasi punto della storia del repository diventa un potenziale punto di partenza per un nuovo branch o per una release. Questo è particolarmente importante in team dove più persone potrebbero basare il loro lavoro su vari punti della cronologia.

Immagina di dover tornare indietro di tre mesi nel codice per indagare su un bug. Se ti ritrovi in un commit dove metà delle funzionalità sono incomplete o il codice non compila nemmeno, il tuo lavoro diventa immensamente più difficile.

Trovare l’Equilibrio

Naturalmente, questi principi richiedono un equilibrio. A volte, soprattutto durante l’esplorazione o la risoluzione di problemi complessi, potresti non essere pronto a creare commit puliti e atomici. In questi casi, strumenti come i branch temporanei o git stash possono aiutarti a salvare il lavoro in corso senza compromettere la qualità della cronologia principale.

Commit atomici: Ogni commit dovrebbe rappresentare un singolo cambiamento logico
Commit frequenti: Meglio tanti piccoli commit che pochi grandi
Commit funzionanti: Ogni commit dovrebbe lasciare il codice in uno stato funzionante

Commit in VS Code

Interfaccia grafica

Source Control Panel: Accedi con l’icona del branch o con Ctrl+Shift+G
Staging files:
- Usa il “+” accanto a ogni file per aggiungerlo alla staging area
- Usa il “-” per rimuoverlo
Commit:
- Inserisci il messaggio nel campo di testo
- Clicca il pulsante di spunta (✓) o usa Ctrl+Enter

Operazioni avanzate in VS Code

Commit parziali: Clic destro su un file -> “Stage Selected Ranges”
Diff view: Clic su un file modificato per visualizzare le differenze
Commit amend: Menu a discesa accanto al pulsante commit
Visualizzazione storia: Estensione “Git History” o “GitLens”
Commit & Push: Menu a discesa accanto al pulsante commit
Commit & Sync: Menu a discesa accanto al pulsante commit

Scorciatoie tastiera in VS Code

Ctrl+Shift+G: Apre pannello Source Control
Ctrl+Enter: Commit dopo aver scritto il messaggio
Alt+Enter: Commit & Push
Ctrl+Shift+P poi “Git: Commit All” o “Git: Stage All Changes”

Best practices

Organizzazione dei Commit

L’organizzazione dei commit è come la composizione musicale: richiede struttura, coerenza e un senso di armonia. Quando segui il principio “un commit, una logica”, ogni modifica diventa una nota distinta nella sinfonia del tuo progetto. Questo approccio rende la storia del codice leggibile come uno spartito ben scritto, dove ogni battuta ha un chiaro proposito.

Separare il refactoring dalle correzioni di bug è fondamentale quanto distinguere tra ritoccare l’arrangiamento di un brano e correggerne le note stonate. Quando mischi questi due aspetti, crei confusione: in caso di problemi, diventa difficile capire se il bug è stato introdotto dalla correzione o dal riarrangiamento del codice. Mantenendoli separati, puoi isolare precisamente l’origine di eventuali problemi.

I commit piccoli e focalizzati sono come frasi brevi e chiare in un discorso: facili da comprendere, verificare e, se necessario, ritrattare. Quando un revisore esamina un commit contenente poche decine di linee con un chiaro scopo, può offrire feedback preciso e pertinente. Allo stesso modo, operazioni come cherry-pick o revert diventano chirurgicamente precise quando applicate a commit ben delimitati.

Un commit, una logica: Ogni commit dovrebbe avere un solo scopo
Separare refactoring da bug fix: Non mischiare in uno stesso commit
Tenere i commit piccoli: Facilitano review, revert e cherry-pick

La Poetica dei Messaggi di Commit

Un buon messaggio di commit è una forma d’arte concisa come l’haiku giapponese. L’uso dell’imperativo presente (“Aggiunge”, “Corregge”, “Rifattorizza”) crea un senso di immediatezza e azione, come se il commit stesso stesse descrivendo cosa fa al progetto nel momento in cui viene applicato. Questa convenzione grammaticale crea uniformità nella narrazione del progetto.

Limitare la prima riga a 50 caratteri è una disciplina che ti costringe alla chiarezza cristallina. Come un titolo di giornale ben scritto, deve comunicare l’essenza del cambiamento in un colpo d’occhio. Questa brevità è particolarmente preziosa quando si sfoglia rapidamente la storia dei commit o si visualizzano log compatti.

Il corpo del messaggio è dove puoi espandere, come un articolo che segue il titolo. Qui non stai semplicemente ripetendo cosa hai fatto (il diff del codice lo mostra già), ma stai spiegando perché l’hai fatto. Quali problemi risolve questo cambiamento? Quali considerazioni hai valutato? Quali alternative hai scartato? Queste spiegazioni sono inestimabili per chi dovrà comprendere le tue decisioni mesi o anni dopo.

I riferimenti a issue tracker creano un ponte tra il codice e il contesto più ampio del progetto. Un semplice “Fixes #123” collega automaticamente il tuo commit alla discussione dettagliata che ha portato alla modifica, creando una rete di conoscenza interconnessa che arricchisce la comprensione del progetto.

Usare imperativo presente: “Aggiunge feature” non “Aggiunta feature”
Prima riga < 50 caratteri: Sommario conciso
Corpo dettagliato se necessario: Spiegare “perché” non solo “cosa”
Riferimenti a issue tracker: “Fixes #123” o “Resolves JIRA-456”

La Tempistica del Commit: Quando Premere il Pulsante

Scegliere il momento giusto per committare è come capire quando concludere un paragrafo in un romanzo. Dopo ogni unità logica completa, hai raggiunto un punto naturale di pausa: la funzionalità è implementata, il bug è risolto, il refactoring è completato. Committare a metà implementazione sarebbe come interrompere una frase a metà.

Creare un commit prima di operazioni rischiose è una rete di sicurezza prudente. Prima di intraprendere quel grande refactoring o quella riscrittura sostanziale, un commit ti offre un punto di ritorno sicuro. È come scattare una foto del puzzle completato prima di mescolare i pezzi per riorganizzarli.

Il commit di fine giornata è una pratica saggia quanto chiudere il diario dopo una giornata produttiva. Ti permette di riprendere il lavoro il giorno successivo sapendo che i tuoi progressi sono al sicuro, e offre una certa pace mentale quando lasci l’ufficio.

Assicurarsi che la storia sia pulita prima di condividere il codice è un atto di rispetto verso i collaboratori. Prima di spingere i tuoi commit o creare una pull request, prenditi un momento per rivedere, riorganizzare e raffinare la tua storia locale. È come rivedere un testo prima di pubblicarlo, assicurandoti che sia chiaro, coerente e privo di passaggi superflui.

Dopo ogni unità logica completa: Non a metà di un’implementazione
Prima di operazioni rischiose: Commit prima di refactoring importanti
Fine della giornata lavorativa: Salvare il progresso giornaliero
Prima di condividere il codice: Assicurarsi che la storia sia pulita

Il Pronto Soccorso Git: Risolvere i Problemi Comuni

Nel viaggio con Git, anche i navigatori esperti possono imbattersi in situazioni complesse. Fortunatamente, Git offre rimedi per quasi ogni infortunio.

Committare nel branch sbagliato è un classico incidente di percorso. La sequenza di comandi per rimediare è come una manovra di recupero ben collaudata: crei un nuovo branch nel punto corrente, ripristini il branch originale all’ultimo commit valido, poi passi al nuovo branch dove il tuo lavoro è al sicuro.

Dimenticare di aggiungere un file al commit è umano quanto dimenticare una chiave uscendo di casa. Il comando --amend è la porta sul retro che ti permette di rientrare e prendere ciò che hai dimenticato, senza che nessuno se ne accorga.

Un messaggio di commit errato è come un lapsus in una conversazione importante. Anche qui, --amend viene in soccorso, permettendoti di riformulare ciò che intendevi dire senza interrompere il flusso della conversazione.

Annullare un commit è un’operazione che richiede decisioni consapevoli, come scegliere quanto indietro tornare in una conversazione difficile. Git ti offre diverse opzioni, dal gentile --soft che mantiene le modifiche pronte per un nuovo commit, al più deciso --hard che cancella completamente le tracce.

Danze di Commit: Integrazione con i Flussi di Lavoro

I vari workflow Git sono come differenti stili di danza, ciascuno con i propri passi e ritmi per i commit.

Nel maestoso Git Flow, i commit seguono una coreografia elaborata. Nei feature branch, i commit frequenti registrano il progresso esplorativo. Il branch develop accoglie i merge di feature complete, mentre release e hotfix vedono commit più misurati e specifici. Il branch master, come un palcoscenico principale, ospita solo esibizioni perfette sotto forma di merge di release verificate.

GitHub Flow propone una danza più semplice ma non meno elegante. I feature branch ospitano lo sviluppo attivo con commit che raccontano la storia dell’implementazione. Le Pull Request riuniscono questi commit per la recensione collettiva. L’opzione “squash and merge” è come la sintesi finale di una lunga improvvisazione, distillando l’essenza del lavoro in un singolo, potente movimento.

Il Trunk-based Development è una danza contemporanea: diretta, continua, spesso audace. I commit piccoli e frequenti fluiscono direttamente nel main/trunk, con feature flags che nascondono i passi incompleti. I sistemi CI/CD fungono da coreografi automatici, verificando che ogni nuovo passo si integri armoniosamente nel flusso complessivo.

Le strategie di merge e commit sono come transizioni tra movimenti diversi. Il merge commit tradizionale preserva ogni passo della storia. Lo squash condensa una sequenza in un unico, potente movimento. Il rebase riscrive elegantemente la cronologia per una narrazione più lineare. Il cherry-pick seleziona con precisione movimenti specifici da riutilizzare in nuovi contesti.

In ogni workflow, l’obiettivo rimane lo stesso: creare una storia del progetto che sia chiara, coerente e utile, permettendo al team di danzare insieme verso l’obiettivo comune di un software eccellente.

Troubleshooting comuni

Anche gli sviluppatori più esperti possono incappare in errori durante l’uso di Git. Vediamo come risolvere alcuni dei problemi più comuni legati ai commit.

Ho committato nel branch sbagliato

Questo errore classico avviene quando realizzi di aver fatto un commit su un branch (ad esempio main) quando invece intendevi lavorare su un nuovo branch.

Soluzione passo-passo:

# 1. Crea un nuovo branch che parta dal punto attuale (con il tuo commit)
git branch corretto

# 2. Torna indietro di un commit sul branch originale
git reset --hard HEAD~1

# 3. Passa al nuovo branch dove il tuo commit è al sicuro
git checkout corretto

È come dire: “Ok, ho lasciato i miei appunti nella stanza sbagliata. Prima creo una copia dei miei appunti, poi ripulisco la stanza sbagliata, e infine mi sposto nella stanza corretta dove ho messo la copia.”

Ho dimenticato di aggiungere un file

A volte fai un commit e subito dopo ti accorgi di aver dimenticato di includere un file importante.

Soluzione passo-passo:

# 1. Aggiungi il file dimenticato alla staging area
git add file_dimenticato

# 2. Modifica l'ultimo commit includendo il nuovo file, mantenendo lo stesso messaggio
git commit --amend --no-edit

L’opzione --no-edit mantiene lo stesso messaggio di commit. È come dire: “Ho spedito un pacco ma ho dimenticato di inserire un oggetto. Riapro il pacco, aggiungo l’oggetto mancante, e lo rispedisco con la stessa etichetta.”

Messaggio di commit errato

Hai fatto un commit ma ti accorgi che il messaggio contiene un errore o non è chiaro.

Soluzione:

# Modifica solo il messaggio dell'ultimo commit
git commit --amend -m "Messaggio corretto"

Questo comando sostituisce il messaggio dell’ultimo commit con quello nuovo. È come correggere un’etichetta su un contenitore senza cambiarne il contenuto.

Voglio annullare un commit

Esistono diversi modi per annullare un commit, a seconda di cosa vuoi fare con le modifiche:

Opzione 1: Mantieni le modifiche pronte per un nuovo commit

git reset --soft HEAD~1

Questo annulla il commit ma mantiene tutte le modifiche nella staging area, pronte per un nuovo commit. È come annullare l’invio di un documento ma tenerlo pronto sulla scrivania.

Opzione 2: Mantieni le modifiche ma riportale nella working directory

git reset HEAD~1  # o git reset --mixed HEAD~1

Questo annulla il commit e rimuove le modifiche dalla staging area, ma le mantiene nel tuo spazio di lavoro. È come riprendere in mano un documento già impacchettato per farci ulteriori modifiche.

Opzione 3: Elimina completamente le modifiche (attenzione!)

git reset --hard HEAD~1

Questo è il più drastico: annulla il commit E elimina tutte le modifiche. È come stracciare un documento e buttarlo via. Usa questa opzione con estrema cautela perché le modifiche verranno perse!

Ricorda che se hai già condiviso (push) i commit con altri, è meglio usare git revert invece di git reset per non creare discrepanze nella storia del repository.

Integrare i Commit nei Flussi di Lavoro Git

Git Flow: La Danza Orchestrata

Git Flow è come una produzione teatrale ben organizzata, dove ogni branch ha un ruolo specifico e i commit seguono un copione preciso. Questo workflow, formalizzato da Vincent Driessen, è ideale per progetti con cicli di rilascio pianificati e team più strutturati.

Nel Git Flow, i feature branch sono i laboratori creativi dove gli sviluppatori sperimentano liberamente. Qui i commit sono frequenti e rappresentano il progresso incrementale dello sviluppo di una funzionalità. È come un pittore che fa numerosi schizzi prima del dipinto finale. Non c’è bisogno di perfezione in ogni commit, ma piuttosto di tracciare il percorso esplorativo.

Il branch develop è come il backstage prima dello spettacolo. Raccoglie tutte le funzionalità completate attraverso commit di merge che integrano il lavoro dai feature branch. Ogni merge rappresenta una nuova funzionalità pronta per il prossimo rilascio.
I branch di release sono come le prove generali. Qui troviamo principalmente commit di bugfix minori o aggiustamenti dell’ultimo minuto. Sono modifiche mirate e contenute, volte a perfezionare il prodotto prima del suo debutto ufficiale.
I branch hotfix sono i soccorritori d’emergenza. Nascono direttamente da master quando c’è un problema critico in produzione. I commit qui sono surgical strikes – interventi chirurgici mirati a risolvere solo il problema specifico, senza introdurre cambiamenti non necessari.
Infine, il branch master è il palcoscenico principale. Qui arrivano solo commit di merge da release o hotfix, rappresentando versioni stabili e testate del software. Ogni commit su master dovrebbe idealmente corrispondere a una nuova versione rilasciabile.

GitHub Flow: La Semplicità Efficace

GitHub Flow è come una jam session di jazz: più semplice, più fluido, ma non meno potente. È particolarmente adatto per sviluppo web continuo e team che praticano deployment frequenti.

Nei feature branch avviene tutto lo sviluppo attivo. I commit raccontano la storia dell’implementazione, con lo stesso livello di libertà e sperimentazione che troviamo in Git Flow. La differenza chiave è che questi branch partono direttamente da main e vi tornano direttamente, senza passare per branch intermedi.
Le Pull Request sono il momento della revisione collettiva. Qui i commit vengono esaminati, discussi e potenzialmente modificati. È un processo collaborativo che assicura qualità e condivisione di conoscenza nel team.
L’opzione “squash and merge” è un potente strumento di sintesi. Permette di consolidare tutti i commit di un feature branch in un unico commit pulito prima di integrarlo in main. È come prendere un romanzo e trasformarlo in un conciso racconto breve che cattura l’essenza della storia, mantenendo la cronologia principale pulita e leggibile.

Trunk-based Development: La Via Diretta

Il Trunk-based Development è come una corsa di maratona dove tutti corrono sulla stessa pista. È un approccio che privilegia l’integrazione continua e la semplicità, ed è particolarmente popolare in team con pratiche DevOps mature.

I commit piccoli e frequenti direttamente sul main (o trunk) sono il cuore di questo approccio. Gli sviluppatori integrano il loro lavoro nel ramo principale più volte al giorno, minimizzando il rischio di conflitti complessi e mantenendo tutti sincronizzati con la versione più recente del codice.
I feature flags (o toggle) sono l’ingegnosa soluzione per nascondere funzionalità incomplete agli utenti finali pur mantenendole nel codice principale. Permettono di committare regolarmente senza interrompere l’esperienza utente. È come costruire una nuova ala di un edificio dietro un muro temporaneo che verrà rimosso solo quando tutto sarà pronto.
I sistemi CI/CD sono i guardiani infaticabili di questo approccio. Ogni commit attiva automaticamente una serie di test e verifiche, assicurando che nessuna modifica possa compromettere la stabilità del main. Questo permette al team di muoversi velocemente con fiducia.

Strategie di Merge e Commit: Gli Strumenti del Mestiere

Le strategie di merge e commit sono come diversi utensili in una cassetta degli attrezzi – ciascuno progettato per uno scopo specifico.

Il merge commit standard (con --no-ff) crea sempre un nuovo commit che rappresenta l’unione di due linee di sviluppo, anche quando sarebbe possibile un fast-forward. Questo mantiene visibile nella storia l’esistenza del branch e offre un quadro completo dello sviluppo. È come conservare sia il prodotto finale che tutti i bozzetti preparatori.
Lo squash è l’arte della condensazione – prende una serie di commit e li comprime in uno solo. È utile quando la storia dettagliata dello sviluppo è importante durante il lavoro ma non necessariamente per la cronologia a lungo termine. È come trasformare un diario di viaggio dettagliato in un conciso album fotografico.
Il rebase è il più elegante e potenzialmente il più pericoloso. Riscrive la storia spostando o combinando commit esistenti, creando una cronologia lineare e pulita. È come riscrivere un libro, mantenendo la trama ma migliorando la struttura e il flusso. Potente per repository personali o branch non condivisi, ma da usare con cautela su codice pubblico.
Il cherry-pick è lo strumento di precisione che permette di selezionare singoli commit da un branch e applicarli a un altro. È utile quando vuoi importare una correzione specifica senza portare altre modifiche. È come scegliere un singolo brano da un album invece di acquistare l’intero disco.

Ogni flusso di lavoro e strategia ha i suoi punti di forza. La scelta migliore dipende dal contesto del progetto, dalle dimensioni del team, dalla frequenza di rilascio e dalla cultura organizzativa. L’importante è che il team scelga un approccio coerente e lo segua con disciplina, adattandolo quando necessario per servire meglio gli obiettivi del progetto.