git commit —amend: correggere l’ultimo commit

git commit --amend serve a sostituire l’ultimo commit con una versione corretta. Puoi cambiare il messaggio, aggiungere un file dimenticato, rimuovere una riga sbagliata o sistemare un typo senza creare un commit-rumore.

La parola chiave è “sostituire”: Git crea un nuovo commit con nuovo hash e sposta il branch a puntarlo.

Perché questa lezione conta

Amend rende la storia locale più pulita. Invece di avere:

feat: aggiungi form login
fix typo
dimenticato file
fix ancora

puoi arrivare a:

feat(auth): aggiungi form login

Ma amend riscrive storia. È corretto su commit locali non condivisi. È rischioso su commit già pushati su branch usati da altri.

Obiettivo operativo

Alla fine della lezione devi saper correggere l’ultimo commit e decidere quando non farlo.

Correggere il messaggio

git commit --amend

Apre l’editor sul messaggio dell’ultimo commit.

Oppure:

git commit --amend -m "fix(auth): valida email vuota"

Prima:

git log -1 --oneline

Dopo:

git log -1 --oneline

Vedrai un hash diverso. Non hai modificato il commit: ne hai creato uno nuovo.

Aggiungere contenuto dimenticato

Scenario:

1. fai commit;
2. ti accorgi che mancava un test;
3. vuoi includerlo nello stesso commit.

git add test/auth.test.ts
git commit --amend --no-edit

--no-edit mantiene il messaggio esistente.

Rimuovere contenuto dall’ultimo commit

Se hai incluso un file per errore:

git restore --staged file

non basta, perché il file è già nel commit. Procedura:

git reset --soft HEAD~1
git restore --staged file-sbagliato
git commit -m "messaggio corretto"

Oppure modifica il file, staged la versione corretta e poi amend.

Commit pubblico o privato

Domanda obbligatoria:

Questo commit è già stato pushato su un branch che altri usano?

Se no: amend va bene.

Se sì: preferisci un nuovo commit correttivo. Riscrivere storia pubblica richiede accordo e, se necessario, --force-with-lease.

Regola pratica:

amend prima del push;
commit correttivo dopo il push condiviso.

Check rapido prima di amend

Prima di amend fai tre controlli:

git status -sb
git log -1 --stat
git branch -vv

status ti dice se stai includendo file non voluti. log -1 --stat ti ricorda cosa contiene davvero l’ultimo commit. branch -vv ti mostra se il branch ha un upstream e quindi se il commit potrebbe essere già parte di una conversazione remota.

Questo minuto di verifica evita l’errore più fastidioso: correggere un commit e, insieme, inglobare modifiche di lavoro non finite.

Amend e PR

Su un branch personale già in PR, amend può essere accettabile se il team si aspetta force push sul branch di feature. Ma deve essere esplicito.

Se la PR è già in review, amendare ogni commento rende difficile seguire cosa è cambiato. In alcuni team è meglio aggiungere commit di fix e squashare alla fine.

Laboratorio guidato

In un repo demo:

1. crea commit con messaggio brutto;
2. correggi solo il messaggio con amend;
3. crea un file dimenticato;
4. aggiungilo con --amend --no-edit;
5. confronta hash prima/dopo;
6. simula scenario “commit già pushato” e decidi cosa faresti.

Output atteso

Una regola scritta:

Uso amend per ripulire l'ultimo commit locale.
Non amend su commit condivisi senza accordo.
Controllo hash e stato prima e dopo.

Errori comuni

Amend dopo push condiviso. Può rompere il lavoro degli altri.

Non capire che cambia hash. Ogni amend crea un nuovo commit.

Usare amend per correggere commit vecchi. Amend riguarda solo l’ultimo commit; per commit precedenti serve rebase interattivo.

Nascondere review. Force push continui durante review possono rendere il processo opaco.

Checklist di verifica

• so correggere messaggio dell’ultimo commit;
• so aggiungere file dimenticati;
• so verificare che l’hash cambia;
• so decidere se il commit è pubblico;
• so quando preferire un commit correttivo.

Collegamenti

• Modulo: Riscrivere la storia: rebase, amend, cherry-pick — lezione 16 del corso.
• Rebase interattivo estende questa idea a più commit.