Hay momentos en los que un cambio se cuela en el repositorio y la manera correcta de deshacerlo no es borrar el pasado, sino añadir un nuevo commit que lo compense. Ahí es donde git revert marca la diferencia: permite deshacer un commit de forma segura, especialmente cuando el historial ya se ha compartido con otras personas o está en una rama protegida.
Si vienes de aprender a crear commits, revisar el historial con git log o comparar cambios con git diff, este paso encaja de forma natural: no siempre hay que corregir hacia atrás, a veces conviene revertir hacia delante.
Qué hace realmente git revert
git revert crea un nuevo commit que aplica la operación inversa de un commit anterior. No borra el commit original, no reescribe el historial y no cambia la línea temporal del proyecto. En términos prácticos, es una forma segura de “cancelar” un cambio sin romper la colaboración.
Esto es distinto de otras estrategias de deshacer cambios en Git. Si necesitas repasar el panorama general, te puede ayudar el artículo sobre cómo deshacer cambios en Git sin perder tu trabajo, donde se explica cuándo conviene cada comando.
Cuándo usarlo
Git revert es ideal cuando el commit ya fue publicado en un repositorio remoto, cuando trabajas en equipo o cuando necesitas mantener un historial limpio y entendible. En estas situaciones, alterar commits antiguos con herramientas destructivas puede generar conflictos innecesarios para el resto del equipo.
También es muy útil en ramas de integración o mantenimiento, donde se necesita desactivar una funcionalidad concreta sin reescribir lo que pasó antes. Esa trazabilidad es especialmente valiosa en proyectos con revisiones de código, CI/CD o despliegues frecuentes.
Sintaxis básica de git revert
La forma más común de revertir un commit es indicar su identificador SHA. Primero localizas el commit con git log y luego ejecutas revert sobre ese hash.
# Revertir un commit concreto
git revert 1a2b3c4
# Git abrirá el editor configurado para escribir el mensaje del nuevo commit
# Guarda y cierra para confirmar la reversión
Si el cambio afectaba a varios archivos, Git aplicará la inversión de esas modificaciones. Si no hay conflictos, el proceso termina con un nuevo commit en tu rama actual.
Revertir el último commit
Cuando el error está en el commit más reciente, puedes revertirlo rápidamente usando HEAD. Es una opción cómoda si detectaste el problema justo después de crear el commit o tras una revisión rápida del historial.
# Revertir el último commit
git revert HEAD
Este enfoque es útil, pero conviene recordar que el nuevo commit no “borra” el original. Ambos seguirán existiendo en el historial, y eso es precisamente lo que lo hace seguro en entornos colaborativos.
Qué ocurre con el historial después de revertir
Después de ejecutar git revert, el historial gana un nuevo commit que representa la отменa del anterior. Si consultas el log, verás una secuencia coherente: commit original, commit de reversión y, después, cualquier otro cambio posterior.
Este comportamiento resulta muy práctico para auditoría y depuración. Si alguna vez necesitas entender por qué se cambió algo, el historial conserva la secuencia completa, algo que no siempre ocurre cuando se reescribe la historia con otras herramientas.
Un ejemplo conceptual
commit A: añade una validación incorrecta
commit B: introduce una funcionalidad nueva
commit C: git revert sobre A
Resultado:
- La validación incorrecta queda anulada
- La funcionalidad de B se mantiene intacta
- El historial sigue siendo lineal y transparente
Esta forma de trabajo encaja muy bien con equipos que necesitan trazabilidad. Si además gestionas ramas, conviene tener claras las bases sobre qué son las ramas en Git y cómo funcionan y cómo se integran los cambios con git merge.
Diferencias entre git revert y git reset
La confusión más habitual aparece con git reset. Ambos comandos sirven para deshacer cambios, pero su filosofía es distinta. Git revert preserva el historial creando un nuevo commit. Git reset, en cambio, mueve la referencia de la rama y puede alterar el historial local.
Si todavía no dominas esta diferencia, merece la pena revisar el artículo sobre cómo utilizar git reset correctamente. En un entorno profesional, entender la frontera entre ambos comandos evita errores costosos.
Regla práctica para no equivocarte
Usa git revert cuando el commit ya está compartido. Usa git reset cuando estás trabajando localmente y sabes que no vas a romper el trabajo de otros. Esa regla simple resuelve la mayoría de casos cotidianos.
Una forma sencilla de recordarlo es pensar en la colaboración: si otras personas pueden haber descargado tu rama, revert suele ser la opción segura. Si no, quizá te convenga otra estrategia de deshacer cambios más flexible.
Qué pasa si aparecen conflictos
Revertir un commit no siempre es automático. Si los mismos archivos han cambiado después del commit original, Git puede encontrar conflictos al intentar aplicar la operación inversa. Esto sucede sobre todo en ramas con mucho movimiento o cuando el cambio original afectaba a zonas de código muy editadas.
Cuando haya conflictos, Git te lo indicará y tendrás que resolverlos manualmente, igual que en una fusión complicada. Después, deberás añadir los archivos corregidos y completar el commit de reversión.
# Ver el estado tras un conflicto
git status
# Una vez resueltos los archivos en conflicto
git add archivo-resuelto.py
git revert --continue
Si durante este proceso quieres inspeccionar exactamente qué cambió, vuelve a apoyarte en git diff. Es una herramienta clave para decidir qué líneas se conservan y cuáles se eliminan.
Revertir varios commits o un merge commit
En escenarios reales, no siempre se revierte un único commit aislado. A veces hay que deshacer una serie de cambios o revertir una fusión completa. Git permite hacerlo, pero conviene actuar con cuidado para no eliminar trabajo válido por accidente.
Cuando el objetivo es revertir varios commits, normalmente se hace uno por uno o se planifica una reversión específica según el orden de dependencias. Con los commits de fusión, el caso es más delicado, porque necesitas indicarle a Git qué línea principal debe tomar como referencia.
# Revertir un merge commit indicando la rama principal como padre 1
git revert -m 1 abcdef0
Este tipo de operación exige entender muy bien la estructura de las ramas y el origen de cada cambio. Si trabajas con integraciones frecuentes, te ayudará repasar cómo fusionar ramas con git merge antes de revertir una combinación compleja.
Buenas prácticas al usar git revert
La primera buena práctica es revisar el commit antes de revertirlo. No te fíes solo del mensaje: inspecciona el contexto con git log y, si hace falta, compara el contenido con git diff.
La segunda es escribir mensajes claros cuando confirmes la reversión. El mensaje del nuevo commit debería indicar qué se revierte y por qué. Eso facilita mucho las revisiones futuras, especialmente si el repositorio tiene varios mantenedores.
La tercera es evitar usar revert como parche permanente. Si un commit se revirtió por un bug, lo normal es que después se estudie la causa raíz y se cree una solución correcta. Revertir es una acción de contención, no siempre la solución definitiva.
Cuándo no es la mejor opción
No siempre conviene revertir. Si el problema está en un commit muy reciente y solo afecta a tu entorno local, otro comando puede ser más apropiado. Del mismo modo, si lo que quieres es recuperar un archivo concreto, quizá te interese más git restore.
La clave está en elegir la herramienta correcta según el estado del proyecto, el nivel de colaboración y el impacto del cambio.
Conclusión
git revert es una de las formas más seguras de deshacer un commit en Git. En lugar de borrar el pasado, lo compensa con un nuevo commit, lo que lo convierte en la opción recomendada cuando trabajas en equipo o cuando el historial ya se ha compartido.
Si dominas git commit, entiendes el historial con git log y sabes cuándo usar git reset, revertir commits te resultará natural. Es una herramienta pequeña, pero esencial para mantener repositorios sanos y colaborativos.
Fuentes y lecturas recomendadas
Documentación oficial de git revert
Documentación oficial de GitHub
Deja una respuesta