Git: borrar ramas, fusionar y deshacer un mal push

August 2, 2026 · – visitantes

Estas tres cosas aparecen todo el tiempo, y de alguna manera los comandos nunca se te quedan del todo entre una vez y la siguiente. Así que aquí están, escritos como es debido.

Borrar una rama

git branch -d feature-x

Esta es la versión segura — Git comprueba antes, y se niega si feature-x tiene commits que nunca llegaron a tu rama actual. Si estás seguro, puedes forzarlo: (1)

git branch -D feature-x

Eso solo la borra en local, eso sí. Si la rama también existe en el remoto (GitHub, por ejemplo), tienes que borrarla ahí por separado:

git push origin --delete feature-x

Algo que vale la pena saber: borrar una rama no borra en realidad sus commits. Simplemente quedan sin referenciar y se quedan en el repositorio hasta que el recolector de basura de Git los vaya barriendo, lo cual puede tardar bastante. Así que git branch -D es más indulgente de lo que parece — si borras la rama equivocada, normalmente todavía hay forma de volver atrás (más sobre esto en la sección del reflog más abajo). Yo no contaría con eso como plan, pero está bien saber que existe.

Fusionar ramas

El patrón habitual es: haz checkout de la rama en la que quieres fusionar, y luego fusiona la otra dentro de ella.

git checkout main
git merge feature-x

Lo que pase después depende de si main se ha movido desde que creaste la rama. Si no se ha movido, Git simplemente adelanta el puntero de main para que coincida con feature-x — un fast-forward, sin commit de merge de por medio. Si main avanzó mientras tanto, Git crea un commit de merge de verdad que une ambos historiales (2).

A veces quieres ese commit de merge incluso cuando un fast-forward habría sido posible — deja una marca visible en el historial de que existió una rama de funcionalidad y se fusionó, en lugar de que el cambio se mezcle en silencio. Para eso:

git merge --no-ff feature-x

Si se tocaron las mismas líneas en ambos lados, Git se detiene y te deja el conflicto para que lo resuelvas:

git status

Eso te listará qué archivos están en conflicto. Abre cada uno, verás marcadores <<<<<<<, ======= y >>>>>>> alrededor de los cambios que compiten — elige lo que de verdad debería quedarse, borra los marcadores, y luego:

git add resolved-file.txt
git commit

Y si la cosa se convierte en más lío del que vale la pena, siempre puedes abandonar todo el intento:

git merge --abort

Eso deja todo exactamente como estaba antes de empezar el merge.

Deshacer un mal push

Este es el que hace que la gente entre en pánico, y sinceramente el pánico normalmente no está justificado — pero aquí sí importa a qué solución recurres.

Si existe alguna posibilidad de que alguien más ya haya hecho pull de la rama, no toques el historial. Añade en su lugar un commit nuevo que deshaga el anterior:

git revert <bad-commit-sha>
git push

Esta es la opción aburrida y siempre segura. No reescribe nada — simplemente añade un commit encima que anula el error, así que el historial de todos se mantiene sincronizado sin que nadie tenga que hacer nada especial por su cuenta (3).

Si la rama es genuinamente solo tuya y nadie le ha hecho pull todavía, puedes rebobinar y reescribir: (4)

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

Usa --force-with-lease, no --force a secas, aunque solo sea por costumbre. La diferencia importa más de lo que parece: --force-with-lease comprueba que nadie haya hecho push a la rama desde tu último fetch, y se niega si lo han hecho. --force a secas no comprueba nada — sobrescribirá alegremente el trabajo de otra persona sin ni siquiera un aviso (5).

Y si estás mirando fijamente tu terminal intentando recordar cuál era el último commit bueno — git log no te va a ayudar aquí, porque solo muestra los commits alcanzables desde donde estás ahora, lo cual no incluye lo que ya descartaste con el reset. Lo que quieres es:

git reflog

Muestra todos los sitios a los que tu rama ha apuntado recientemente, incluidos los que se salieron del historial normal. Retrocede hasta antes de que las cosas se torcieran, y luego: (6)

git reset --hard HEAD@{2}

(cambia esto por la posición o el SHA que corresponda a tu caso). El reflog es local a tu máquina y generalmente conserva las entradas durante unos 90 días, así que es menos un "deshacer de emergencia para pushes malos" y más una red de seguridad general para "creo que acabo de romper algo" — vale la pena recordar que existe incluso fuera de esta situación concreta.

Reflexión final

Estas tres cosas se apoyan en el mismo hecho subyacente: Git casi nunca tira nada de inmediato. Ramas borradas, commits reseteados, posiciones antiguas de una rama — todo eso se queda dando vueltas más tiempo del que parece. Eso es realmente lo que hace que -D, reset --hard y el force-push sean lo bastante seguros para usar en el día a día, siempre que sepas dónde buscar si alguno de ellos resulta ser un error.

Lecturas Relacionadas

Entendiendo Make — qué dispara realmente una recompilación

Para seguir leyendo

git-branch — creación, listado y borrado de ramas.
git-merge — estrategias de merge y resolución de conflictos.
git-revert — deshacer commits creando otros nuevos.
git-reset — mover el puntero de una rama, con la diferencia entre --soft, --mixed y --hard.
git-push: --force-with-lease — por qué es más seguro que --force.
git-reflog — recuperar commits que ya no aparecen en el historial normal.