Git: eliminare branch, fare merge e annullare un push sbagliato

August 2, 2026 · – visitatori

Queste tre cose spuntano fuori di continuo, e in qualche modo i comandi non restano mai davvero in testa da una volta all'altra. Quindi eccoli qui, scritti per bene.

Eliminare un branch

git branch -d feature-x

Questa è la versione sicura — Git controlla prima, e rifiuta se feature-x ha commit che non sono mai arrivati nel tuo branch attuale. Se sei sicuro, puoi forzare: (1)

git branch -D feature-x

Questo però lo elimina solo in locale. Se il branch esiste anche sul remote (GitHub, per dire), devi eliminarlo lì separatamente:

git push origin --delete feature-x

Una cosa che vale la pena sapere: eliminare un branch non elimina davvero i suoi commit. Diventano semplicemente non referenziati e restano nel repository finché il garbage collector di Git prima o poi non li spazza via, il che può richiedere un bel po'. Quindi git branch -D è più indulgente di quanto sembri — se elimini il branch sbagliato, di solito c'è ancora un modo per tornare indietro (ne parlo più avanti, nella sezione sul reflog). Non ci farei affidamento come piano, ma è bene sapere che c'è.

Fare merge dei branch

Lo schema classico è: fai checkout del branch in cui vuoi fare il merge, poi ci fondi dentro l'altro.

git checkout main
git merge feature-x

Cosa succede dopo dipende dal fatto che main si sia mosso o meno da quando hai creato il branch. Se non si è mosso, Git si limita a far avanzare il puntatore di main fino a farlo coincidere con feature-x — un fast-forward, senza commit di merge di mezzo. Se main nel frattempo è andato avanti, Git crea un vero commit di merge che unisce le due storie (2).

A volte vuoi quel commit di merge anche quando un fast-forward sarebbe stato possibile — lascia un segno visibile nella storia che un branch di funzionalità è esistito ed è stato unito, invece di far confluire il cambiamento in silenzio. Per farlo:

git merge --no-ff feature-x

Se sono state toccate le stesse righe da entrambe le parti, Git si ferma e ti lascia il conflitto da risolvere:

git status

Questo elencherà quali file sono in conflitto. Aprili uno per uno, vedrai marcatori <<<<<<<, ======= e >>>>>>> intorno alle modifiche in competizione — scegli cosa deve effettivamente restare, elimina i marcatori, poi:

git add resolved-file.txt
git commit

E se la cosa si trasforma in un pasticcio più grande di quanto valga la pena, puoi semplicemente tirarti fuori da tutto quanto:

git merge --abort

Questo riporta tutto esattamente com'era prima che iniziassi il merge.

Annullare un push sbagliato

Questo è quello per cui la gente va nel panico, e onestamente il panico di solito non è giustificato — ma qui è davvero importante quale soluzione scegli.

Se c'è anche solo la possibilità che qualcun altro abbia già fatto il pull del branch, non toccare la storia. Aggiungi invece un nuovo commit che annulla quello vecchio:

git revert <bad-commit-sha>
git push

Questa è l'opzione noiosa e sempre sicura. Non riscrive niente — aggiunge semplicemente un commit sopra che cancella l'errore, così la storia di tutti resta sincronizzata senza che nessuno debba fare niente di speciale dalla propria parte (3).

Se il branch è davvero solo tuo e nessuno l'ha ancora tirato giù, puoi riavvolgere e riscrivere: (4)

git reset --hard <last-good-commit-sha>
git push --force-with-lease

Usa --force-with-lease, non --force semplice, anche solo per abitudine. La differenza conta più di quanto sembri: --force-with-lease controlla che nessuno abbia fatto push sul branch dal tuo ultimo fetch, e rifiuta se qualcuno l'ha fatto. --force semplice non controlla niente — sovrascriverà allegramente il lavoro di qualcun altro senza nemmeno un avviso (5).

E se te ne stai lì a fissare il terminale cercando di ricordare quale fosse l'ultimo commit buono — git log qui non aiuta, perché mostra solo i commit raggiungibili da dove ti trovi ora, il che non include quello da cui ti sei già staccato con il reset. Quello che ti serve è:

git reflog

Mostra ogni punto a cui il tuo branch ha puntato di recente, compresi quelli usciti dalla storia normale. Torna indietro fino a prima che le cose si mettessero male, poi: (6)

git reset --hard HEAD@{2}

(sostituisci con la posizione o lo SHA che corrisponde davvero al tuo caso). Il reflog è locale alla tua macchina e in genere conserva le voci per circa 90 giorni, quindi è meno un "annulla di emergenza per i push sbagliati" e più una rete di sicurezza generale per "credo di aver appena rotto qualcosa" — vale la pena ricordarsi che esiste anche al di fuori di questa situazione specifica.

Riflessione finale

Tutte e tre queste cose si appoggiano allo stesso fatto di fondo: Git quasi non butta mai via niente subito. Branch eliminati, commit resettati, vecchie posizioni su un branch — tutto questo resta in giro più a lungo di quanto sembri. Ed è proprio questo che rende -D, reset --hard e il force-push abbastanza sicuri da usare tutti i giorni, purché tu sappia dove andare a cercare se uno di questi si rivela un errore.

Letture Correlate

Capire Make — cosa fa scattare davvero una ricompilazione

Per approfondire

git-branch — creazione, elenco ed eliminazione dei branch.
git-merge — strategie di merge e risoluzione dei conflitti.
git-revert — annullare commit creandone di nuovi.
git-reset — spostare il puntatore di un branch, con la differenza tra --soft, --mixed e --hard.
git-push: --force-with-lease — perché è più sicuro di --force.
git-reflog — recuperare commit che non compaiono più nella storia normale.