Come modificare l'ultimo commit in Git (messaggio, file, autore e annullamento)

Per correggere il commit più recente sul tuo ramo corrente, esegui git commit --amend. Se non è presente nulla, Git sostituisce il commit con il tuo messaggio aggiornato; se prima metti in stage le nuove modifiche, Git inserisce tali modifiche nel commit e ti consente di mantenere il messaggio esistente con --no-edit o di riscriverlo al suo posto. Preferisci un flusso di lavoro visivo? In GitTree su macOS, Windows e Linux, attiva Modifica commit precedente nel pannello di commit (o fai clic con il pulsante destro del mouse sul commit principale nel grafico e scegli Modifica messaggio di commit…) per precompilare il messaggio, mettere in stage o rimuovere dallo stage singole righe, visualizzare un avviso di ramo remoto prima di riscrivere la cronologia inviata e ripristinare in qualsiasi momento con un clic Annulla.

Riferimento rapido: ogni comando git commit --amend

Scegli il comando esatto che corrisponde a ciò che non va nel tuo ultimo commit oppure passa alla sezione dettagliata di seguito per casi limite, hook, commit firmati e alternative visive.

Ciò che git commit --amend fa effettivamente dietro le quinte

Ogni hash di commit Git è un checksum crittografico (SHA-1 o SHA-256) calcolato da cinque parti di dati: lo snapshot dell'albero root, gli hash di commit genitore, il nome/e-mail/timestamp dell'autore, il nome/e-mail/timestamp del committer e il messaggio di commit. Cambia anche un singolo carattere nel messaggio, o il timestamp del committente, un secondo dopo, e l'hash risultante sarà completamente diverso.

# Before git commit --amend:
A --- B --- C  <-- main (HEAD)

# After git commit --amend:
A --- B --- C' <-- main (HEAD)
       \
        C      (still in git reflog as HEAD@{1} until garbage collection)

Quando esegui git commit --amend, Git prende tutto ciò che è attualmente nell'area di staging (l'indice), lo combina con i puntatori principali di C (B), scrive un nuovo oggetto di commit C' e aggiorna il riferimento al ramo corrente in modo che punti a C'. Il commit originale C non viene eliminato immediatamente: rimane registrato nel tuo reflog locale (HEAD@{1}) per almeno 30-90 giorni (gc.reflogExpireUnreachable), motivo per cui una modifica accidentale è sempre recuperabile localmente, tramite git reflog o tramite gli strumenti Annulla e ripristina e Lost & Found di GitTree.

1. Modifica l'ultimo messaggio di commit

Se hai appena effettuato il commit e hai notato immediatamente un errore di battitura, un numero di problema Jira/GitHub errato o un prefisso Conventional Commits mancante (feat:, fix:, chore:), controlla prima git status in modo da sapere se c'è qualcosa in scena.

Passa un nuovo messaggio di una riga o multiparagrafo con -m

Per sostituire il messaggio direttamente dal terminale senza avviare un editor, passa -m. Puoi concatenare più flag -m per creare una riga di oggetto e paragrafi del corpo:

# Replace the commit subject inline
git commit --amend -m "fix(auth): validate refresh token expiry before rotation"

# Replace both the subject line and body paragraph
git commit --amend \
  -m "fix(auth): validate refresh token expiry before rotation" \
  -m "Prevents expired tokens from issuing a new session when clock skew exceeds 30s."

Modifica il messaggio esistente nel tuo editor di testo

Quando il tuo commit ha già una descrizione dettagliata su più righe, trailer (Co-authored-by:, Signed-off-by:) o riferimenti a problemi che non desideri ridigitare, esegui git commit --amend senza -m:

git commit --amend

Git apre il tuo core.editor configurato (Vim, Nano, VS Code, Zed, ecc.) con il messaggio di commit corrente precaricato. Salvare e chiudere il file per scrivere il commit modificato. Se cambi idea mentre l'editor è aperto, elimina l'intero messaggio di commit (lasciando il file vuoto) e salva: Git interrompe la modifica con Aborting commit due to empty commit message e lascia HEAD intatto.

2. Aggiungi file dimenticati o righe specifiche all'ultimo commit

Dimenticare di salvare un file, organizzare un dispositivo di prova o eseguire il formattatore prima di fare commit è il motivo più comune per cui gli sviluppatori scelgono --amend. Metti prima in scena le modifiche mancanti, poi modifica con --no-edit in modo che Git mantenga il messaggio di commit esistente senza aprire un editor:

# Stage the forgotten file (or files)
git add src/auth/token-validator.test.ts

# Fold the staged file into the last commit and keep the existing message
git commit --amend --no-edit

Metti in stage solo linee o parti specifiche prima di modificarle

Cosa succede se il tuo albero di lavoro contiene sia la correzione di 3 righe che appartiene al commit precedente *e* 40 righe di registrazione del debug o lavoro per la tua prossima funzionalità? Non eseguire git add . o git commit -a --amend. Invece, metti in stage solo i blocchi o le linee esatte che appartengono al commit precedente utilizzando la modalità patch (trattata in dettaglio nella nostra guida a git add -p e alla staging di linee specifiche):

# Choose y/n/s (split) for each changed hunk
git add -p src/auth/token-validator.ts

# Verify what is staged vs what stays in the working tree
git diff --staged

# Amend the last commit with only the staged hunks
git commit --amend --no-edit

In GitTree, non devi mai lottare con la suddivisione del terminale (s, e) per fare questo: fai clic su qualsiasi file in Modifiche non organizzate, seleziona le righe esatte o fai clic su Stage Hunk nel confronto affiancato o in linea e attiva Modifica commit precedente. Consulta la nostra guida alle differenze Git per vedere come l'ispezione delle differenze in fasi rispetto a quelle non in fasi impedisce al codice accidentale di scivolare in un commit modificato.

3. Rimuovere un file memorizzato per errore (senza eliminarlo dal disco)

Supponiamo che tu abbia eseguito git add . e abbia accidentalmente eseguito il commit di un file .env.local, un artefatto di build di grandi dimensioni o un file che appartiene a una richiesta pull separata. Il modo in cui lo rimuovi da HEAD dipende dal fatto che il file esistesse nel commit prima di HEAD (HEAD~1) o sia stato aggiunto di recente in HEAD.

Caso A: rimuovi un file appena aggiunto dall'ultimo commit (mantieni il file locale)

Utilizza git rm --cached per rimuovere il file dall'indice di staging lasciando il file fisico sul disco, quindi modifica:

# Remove the file from the index only (leaves the file on disk)
git rm --cached .env.local

# Optional: add it to .gitignore so it never gets staged again
echo ".env.local" >> .gitignore
git add .gitignore

# Rewrite the last commit without .env.local
git commit --amend --no-edit

Caso B: ripristina le modifiche a un file tracciato nell'ultimo commit (mantieni le modifiche locali)

Se <file> era già tracciato in HEAD~1 e hai accidentalmente incluso delle modifiche in HEAD, non utilizzare git rm --cached (questo registrerebbe un'eliminazione di file in HEAD!). Ripristina invece la voce di indice per quel file da HEAD~1:

# Reset only the staged index state of <file> back to HEAD~1
git restore --source=HEAD~1 --staged src/config/database.ts

# Amend HEAD: the commit no longer touches database.ts, and your local edits stay in the working tree
git commit --amend --no-edit

Se invece desideri eliminare le modifiche locali indesiderate o pulire completamente i file non tracciati, vedi come eliminare le modifiche e pulire i file non tracciati in Git e come ripristinare un file eliminato in Git.

4. Modifica l'autore, l'e-mail o il timestamp dell'ultimo commit

Quando esegui il commit su un nuovo laptop prima di impostare user.email o il commit all'interno di un repository di lavoro mentre la tua email personale GitHub è configurata a livello globale, il commit registra l'identità errata. git commit --amend può riscrivere i metadati del commit senza toccare un singolo file.

# Option 1: Set an explicit author name and email on the last commit
git commit --amend --author="Jane Doe <jane@company.com>" --no-edit

# Option 2: Update git config first, then reset the commit author to match
git config user.name "Jane Doe"
git config user.email "jane@company.com"
git commit --amend --reset-author --no-edit

# Option 3: Amend the author date as well
git commit --amend --date="2026-11-11T14:30:00+02:00" --no-edit

5. Come modificare in sicurezza un commit che hai già inviato

Non appena modifichi un commit che è già stato inviato a origin, il tuo ramo locale e il ramo di monitoraggio remoto (origin/<branch>) divergono: il tuo ramo locale ha C', mentre origin ha ancora C. Entrambi i commit condividono il genitore B.

Se il ramo è una tua funzionalità o un ramo di richiesta pull, aggiorna il remoto in modo sicuro con --force-with-lease (e --force-if-includes in Git 2.30+):

# Safely replace the remote branch tip with your amended commit
git push --force-with-lease --force-if-includes origin HEAD

• Perché `--force-with-lease` invece di `--force`: Il semplice git push --force sovrascrive ciecamente il ramo remoto, cancellando qualsiasi commit inviato da un compagno di squadra o da un bot CI dall'ultimo recupero. --force-with-lease controlla che origin/<branch> punti ancora all'esatto SHA di commit archiviato nel tuo riferimento di monitoraggio remoto locale; se qualcun altro ha inviato nel frattempo, Git rifiuta il push invece di perdere il proprio lavoro.
• Cosa aggiunge `--force-if-includes`: Se hai abilitato il recupero automatico in background, il riferimento del monitoraggio remoto potrebbe aggiornarsi prima dell'invio. --force-if-includes verifica che il commit all'estremità del ramo remoto sia stato effettivamente integrato nel tuo reflog locale prima di consentire la riscrittura.
• Quando sei su `main` o su un ramo condiviso: non modificare e forzare il push di un ramo condiviso su cui altri sviluppatori basano il loro lavoro. Invece, lascia il commit intatto ed esegui il push di un nuovo commit di correzione, oppure invertilo in modo pulito con git revert (consulta la nostra guida per ripristinare commit e unioni e il tutorial Recover Pushed Mistakes).
• Devi prima configurare il ramo di monitoraggio? Vedi come impostare un ramo upstream in Git.

6. Cosa succede se il commit che devi modificare NON è l'ultimo commit?

git commit --amend riscrive sempre e solo HEAD (il tip commit). Quando l'errore di battitura o la modifica mancante appartiene a HEAD~2 o tre commit indietro, hai due opzioni pulite, senza mettere da parte manualmente lo stashing e selezionare attentamente:

Opzione 1: squash automatico rapido della CLI con git commit --fixup

Metti in stage la correzione, crea un commit --fixup prendendo di mira lo SHA del commit precedente (o --fixup=amend:<sha> per modificarne anche il messaggio) ed esegui git rebase -i --autosquash:

# 1. Stage the changes meant for the older commit (e.g. a1b2c3d)
git add src/api/client.ts

# 2. Create a fixup commit targeting a1b2c3d
git commit --fixup=a1b2c3d

# 3. Autosquash the fixup commit straight into a1b2c3d
GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash a1b2c3d~1

Opzione 2: rebase visivo interattivo in GitTree

Invece di copiare SHA e modificare i file delle cose da fare di rebase nel terminale, leggi la nostra guida interattiva alla GUI di rebase e la guida al rebase di branch completa. Nel pianificatore Interactive Rebase e Reword, Squash and Drop di GitTree, fai clic con il pulsante destro del mouse su qualsiasi commit precedente nel grafico, scegli Rebase interattivo da qui…, cambia il commit in Reword o trascina un commit di correzione su di esso in Fixup/Squash e applicalo con un clic.

7. Come annullare un commit git accidentale --amend

Hai eseguito git commit --amend durante lo stage di file non desiderati o hai sovrascritto accidentalmente un messaggio di commit di cui avevi bisogno? Poiché Git registra ogni movimento di HEAD nel reflog locale, il tuo commit pre-modifica è ancora al sicuro su HEAD@{1}.

# 1. Inspect the reflog to see the amend and the commit before it
git reflog -n 5
# e9f8d7c (HEAD -> feature) HEAD@{0}: commit (amend): feat: add billing webhook
# 4a3b2c1 HEAD@{1}: commit: feat: add billing webhook

# 2. Restore the branch to the pre-amend commit and keep any extra changes staged
git reset --soft HEAD@{1}

L'utilizzo di git reset --soft HEAD@{1} riporta il puntatore del ramo direttamente sul commit originale (4a3b2c1) e lascia la differenza tra il commit modificato e il commit originale in stage nel tuo indice: nulla nel tuo albero di lavoro viene perso. Per un approfondimento sui ripristini e sul ripristino del reflog di soft, mixed e hard, leggi Git reset --soft vs --mixed vs --hard, come annullare git reset, rebase o commit con reflog e come recuperare gli stash rilasciati e i commit penzolanti.

Quando utilizzare git commit --amend vs reset, revert o rebase -i

Utilizza questa matrice decisionale ogni volta che devi correggere la cronologia in modo da scegliere il comando che corrisponde alla posizione del tuo commit e se i compagni di squadra lo hanno eseguito:

Come GitTree elimina ogni errore comune di git commit --amend

La maggior parte degli incidenti di modifica della riga di comando si verificano perché il terminale nasconde tre elementi critici di contesto finché non è troppo tardi: cosa è già presente nella tua area di staging, se HEAD è già stato inviato a origin e quale era il precedente SHA di commit prima che tu lo sovrascrivessi. GitTree risolve ciascuna di queste modalità di errore direttamente nell'interfaccia:

• Ispezione delle differenze in fasi e non in tempo reale: prima di fare clic su Modifica commit, l'elenco Modifiche graduali si trova direttamente sopra la casella di commit in modo da non poter mai piegare accidentalmente file semifiniti in HEAD. Puoi organizzare o rimuovere dallo stage singole linee, blocchi o file con un clic (Stage Files, Hunks and Lines).
• Rilevamento push-commit e protezione Force-Push-With-Lease: Quando HEAD è già sul ramo remoto, GitTree ti avvisa direttamente nel pannello di commit *prima* di modificare e associa il flusso di lavoro con Force Push (With Lease)… in modo da non sovrascrivere mai il push di un compagno di squadra.
• Riformulazione con il tasto destro del mouse e creazione rapida di `fixup!`/`amend!`: Vuoi riformulare HEAD senza toccare i file in fase di stage? Fai clic con il pulsante destro del mouse sul commit principale nel grafico dei commit e scegli Modifica messaggio di commit…. Hai bisogno di correggere un commit precedente? Fai clic con il pulsante destro del mouse sul commit precedente nel grafico per creare un commit fixup! o amend! o aprire Interactive Rebase.
• Istantanee di sicurezza automatiche (`refs/ogt/trash`) e annullamento con un clic: Prima di eseguire una qualsiasi delle 19 operazioni di modifica della cronologia, tra cui Modifica di un commit, rebase interattivo, ripristino, eliminazione di rami ed eliminazione, GitTree registra uno snapshot locale in refs/ogt/trash. Facendo clic su Annulla (Cmd+Z / Ctrl+Z) si ripristina immediatamente l'esatto stato di commit e staging precedente alla modifica.
• Terminale Lost & Found visivo e integrato: Anche se hai apportato modifiche dal terminale integrato o settimane fa, Lost & Found risulta irraggiungibile e ha sostituito i commit con i relativi differenziali completi in modo da poterli ripristinare, selezionare o diramare da essi senza analizzare l'output git reflog non elaborato.
• Git Hook, avvisi segreti e messaggi di commit AI: GitTree esegue gli pre-commit e i commit-msg Git hook del tuo repository, controlla le differenze in fasi per chiavi API accidentali e (in GitTree Pro) consente a Nour di generare messaggi di commit accurati utilizzando il tuo agente di codifica locale.