Git revert: qué es, cuándo usarlo y cómo deshacer cambios sin romper el historial

Git revert: deshacer cambios de forma segura (sin reescribir historia)

Si trabajas con Git en equipo, hay un momento en que “deshacer” algo deja de ser trivial.

Porque en proyectos reales, normalmente:

la rama está compartida
ya hiciste push
otros ya basaron su trabajo en ese historial

Y ahí aparece la pregunta clásica:

¿Cómo deshago un commit sin romperle el día a mi equipo?

La respuesta más sana casi siempre es: git revert.

Qué hace exactamente `git revert`

git revert no borra un commit.

Lo que hace es crear un nuevo commit que aplica la operación inversa del commit que quieres deshacer.

Dicho simple:

commit original: “sumé estos cambios”
revert: “resté esos mismos cambios”

Y lo mejor: el historial queda intacto, lo que lo hace ideal para ramas públicas (como main, develop, release).

Revertir un commit específico (caso típico)

Supongamos que el commit abc123 introdujo un bug.

Para revertirlo:

git revert abc123

Git:

genera un commit nuevo
aplica el inverso del diff del commit original
te abre el editor para el mensaje del commit

Si haces git log, verás ambos commits:

el commit original (sigue existiendo)
el commit de revert (lo neutraliza)

Por qué `git revert` es “seguro” para equipos

Porque no reescribe historia.

Cuando tú haces push de un revert:

nadie tiene que hacer git pull --rebase raro
nadie sufre con force push
el historial sigue siendo coherente y trazable

En resumen: revert es el “deshacer” recomendado cuando el commit ya está compartido.

Revert con mensaje automático (útil para velocidad)

Si no quieres abrir editor interactivo:

git revert --no-edit abc123

Git genera un mensaje estándar tipo:

Revert ""

Esto es súper útil en hotfixes rápidos.

Revertir varios commits

Hay dos formas comunes:

1) Revertir uno por uno (simple y controlable)

git revert a1b2c3
git revert d4e5f6

2) Revertir un rango (cuando sabes exactamente lo que haces)

git revert OLDEST^..NEWEST

El ^ es clave: incluye el commit más antiguo del rango.

Qué pasa si hay conflictos al revertir

Sí: revert también puede causar conflictos.

Pasa cuando:

el código ya cambió desde ese commit
el revert intenta “deshacer” líneas que ya no están igual

El flujo es el mismo de siempre:

git status
# resuelves conflictos
git add .
git revert --continue

Si decides abortar:

git revert --abort

Revertir un merge commit (ojo aquí)

Revertir un merge no es lo mismo que revertir un commit normal.

Si intentas:

git revert <merge-hash>

Git te pedirá un “mainline” (-m) porque un merge tiene dos (o más) padres.

¿Qué es `-m`?

Es decirle a Git cuál padre considerar como la línea principal.

Ejemplo típico (merge de feature a main):

git revert -m 1 <merge-hash>

-m 1 = considera el primer padre como base (normalmente main)

Este punto merece respeto: revertir un merge puede ser correcto, pero también puede dejar el árbol raro si no entiendes el contexto.

`git revert` vs `git reset`: no son lo mismo

Aquí muchos se confunden.

`git reset` (reescribe historia)

mueve el puntero de la rama a otro commit
puede eliminar commits “de la historia” local
si ya hiciste push, reset suele implicar force push

git reset --hard HEAD~1

Esto es útil en ramas personales o cuando nadie más depende de tu historial.

`git revert` (no reescribe historia)

crea un commit nuevo inverso
es el camino seguro para ramas compartidas

Regla práctica:

¿ya hiciste push a una rama compartida? → revert
¿estás en tu rama local y quieres limpiar? → reset

Revert vs cherry-pick: parecen primos, pero hacen lo opuesto

Esta comparación aparece mucho en búsquedas, así que dejémosla redonda.

`git revert`

“Quiero deshacer el efecto de este commit”

crea un commit inverso
elimina el efecto, no el historial

`git cherry-pick`

“Quiero traer el efecto de este commit a esta rama”

copia cambios de un commit
los aplica en otra rama

En otras palabras:

revert mira hacia atrás (deshace)
cherry-pick mira hacia otro lugar (trae)

Ejemplo real: bug en producción y flujo saludable

Escenario:

main está en producción
alguien mergeó un commit que rompe un flujo
necesitas volver a la normalidad rápido

Camino recomendado

identificas el commit problemático

git log --oneline

lo reviertes

git checkout main
git pull
git revert --no-edit <hash>

haces push y despliegas

git push

Resultado:

el bug deja de existir
el historial sigue claro
el equipo no sufre

Ejemplo real: revertir para “parar la hemorragia” y luego arreglar bien

Esto es muy real en equipos:

revertir rápido para estabilizar
luego hacer el fix real con calma

¿Por qué?

Porque a veces el mejor movimiento es ganar tiempo sin improvisar más.

Revertir un revert (sí, también existe)

Dato sabroso: si revertiste un commit y te diste cuenta que no era el problema…

Puedes revertir el revert.

git revert <hash-del-revert>

Eso re-aplica los cambios originales.

Es como un “undo del undo”, manteniendo historial.

Un cierre práctico para que no te equivoques

Si te quedas con una sola idea, que sea esta:

git revert es el botón de seguridad cuando ya compartiste historia.

Y si lo piensas como regla de equipo:

en ramas públicas: revert
en tu rama local: reset
para llevar cambios puntuales a otra rama: cherry-pick

Cuando entiendes eso, Git deja de sentirse como magia negra y se vuelve una herramienta de control real.