Deshacer errores en git: reset, revert y reflog

En pocas palabras: Para deshacer errores en Git, usá git reset --soft HEAD~1 si el commit no se publicó, git revert <hash> si ya hiciste push y git reflog para recuperar commits perdidos. Reflog conserva las entradas 90 días por defecto, 30 si son inalcanzables.

Para deshacer errores en git, el comando depende de dos cosas: si ya hiciste push y si el cambio estaba commiteado. Con git reset --soft HEAD~1 sacás el último commit sin perder cambios, git revert corrige lo ya publicado y git reflog rescata commits perdidos.

Deshacer errores en git es usar un conjunto de comandos (commit --amend, reset, restore, revert y reflog) para corregir commits, ramas y archivos sin rehacer el trabajo. Es una tarea de cualquier persona que use Git, y cada comando tiene un riesgo distinto: unos tocan solo tu copia local, otros reescriben historial compartido y uno borra cambios sin vuelta atrás.

¿Qué se puede y qué no se puede al deshacer errores en git?

Casi todo lo que commiteaste se puede recuperar, y casi nada de lo que nunca commiteaste ni pasaste por staging. Según el post de dev.to publicado el 10 de octubre de 2026, Git guarda mucho historial y por eso la mayoría de los errores tiene arreglo.

El post recorre siete errores comunes y marca cada arreglo como seguro o como capaz de borrar trabajo. Para elegir comando alcanzan dos preguntas: si el cambio estaba commiteado y si ya hiciste push. Sin commit no hay red de seguridad. Con push, reescribir historial deja de ser un asunto personal. Lo que el post no cubre son merges ni rebases, y esta nota tampoco.

¿Cómo cambio el mensaje del último commit o lo deshago sin perder cambios?

Si todavía no hiciste push, git commit --amend -m "Mensaje mejor" reemplaza el último commit por uno nuevo con otro mensaje, y git reset --soft HEAD~1 saca el commit y deja tus cambios en staging para que edites y vuelvas a commitear. Después de un push, evitá amend: cambiar historial publicado le complica la vida al resto del equipo. Para más detalles técnicos, mirá qué puede fallar al desplegar a producción.

Las tres variantes de reset se distinguen por lo que pasa con tus cambios:

Opción	Qué pasa con el commit	Qué pasa con tus cambios	Riesgo
--soft	Se elimina	Quedan en staging	No borra trabajo
--mixed (por defecto)	Se elimina	Quedan sin staging	No borra trabajo
--hard	Se elimina	Se borran	Destructivo

Ojo con --hard. Es el único de los tres que se lleva tus cambios, y el post lo marca como el que hay que usar con cuidado (tomalo en serio: si ya lo corriste, andá directo al reflog, más abajo).

¿Cómo saco un archivo del staging o descarto los cambios de un archivo?

git restore --staged archivo.js saca el archivo del staging y deja los cambios intactos en tu disco, así que es seguro. git restore archivo.js, en cambio, devuelve el archivo a la última versión commiteada y no se puede deshacer. En versiones viejas de Git, lo primero se hacía con git reset HEAD archivo.js.

Ponele que corriste git add . y se coló config.local.js (ejemplo hipotético, pero cualquiera se topó con algo parecido). El --staged lo saca del próximo commit sin tocar una línea. El segundo comando es otra historia: el autor del post lo resume con “Git has no copy of changes you never committed or staged”, es decir, Git no guarda copia de lo que nunca commiteaste ni pasaste por staging. Más contexto en base de errores de GitHub Actions consultable.

Corré git diff antes. Siempre.

¿Qué hago si commiteé en la rama equivocada?

Para pasar un commit de main a otra rama hacen falta tres comandos: crear la rama nueva en el commit actual, volver main al estado remoto y cambiarte a la rama nueva. El commit queda a salvo en la rama nueva y main queda limpia. La receta sale del post de dev.to, con feature como nombre de ejemplo.

git branch feature
git reset --hard origin/main
git switch feature

El orden importa: primero creás la rama, que protege el commit, y recién después retrocedés main. Como git reset --hard borra cualquier cambio sin commitear, commiteá o hacé stash antes de empezar.

Propuesta editorial, que no viene de la fuente: antes del reset, corré git fetch y git log --oneline origin/main..main para ver qué commits vas a mover. Si la lista muestra más de los que esperabas, frená y revisá.

¿Cómo deshago un commit que ya hice push?

git revert <hash> crea un commit nuevo que hace lo opuesto al commit malo, sin reescribir el historial compartido. Es la forma segura de deshacer trabajo ya publicado, porque la historia queda honesta y a nadie se le rompe su copia. El hash lo sacás de git log --oneline.

Supongamos que git log --oneline muestra e4f5a6b Add login form (hash y mensaje tomados del ejemplo del post) y ese commit rompió el login. Corrés git revert e4f5a6b, subís el commit resultante y listo. Tema relacionado: comparativa de herramientas de CI/CD.

Si forzar el push es inevitable, usá git push --force-with-lease, que se niega a pisar trabajo que no viste. Es una red de seguridad que el --force a secas no tiene.

¿Qué es git reflog y cómo recupero commits perdidos o una rama borrada?

git reflog administra los reflogs, registros locales de dónde estuvieron las puntas de las ramas y HEAD. Sirve para encontrar el hash de un commit que parece perdido tras un reset --hard o un borrado de rama, y con ese hash creás una rama de rescate: git branch recovered e4f5a6b.

Así se ve la salida en el ejemplo del post:

a1b2c3d HEAD@{0}: reset: moving to HEAD~2
e4f5a6b HEAD@{1}: commit: Add login form
c7d8e9f HEAD@{2}: commit: Add user model

Según la documentación oficial de git-reflog, HEAD@{2} es el lugar donde estaba HEAD dos movimientos atrás, y git reflog show es un alias de git log -g --abbrev-commit --pretty=oneline.

Hay dos límites. El reflog solo registra commits, así que no trae de vuelta cambios que nunca commiteaste. Y las entradas vencen: el post dice que duran entre 30 y 90 días, y la documentación precisa que por defecto son 90 días para entradas alcanzables (gc.reflogExpire) y 30 para las no alcanzables (gc.reflogExpireUnreachable). Mi lectura, que es inferencia y no figura en el post: un commit huérfano tras un reset --hard ya no es alcanzable desde ninguna rama, así que probablemente corra con el plazo corto de 30 días.

Ponele que corrés el reset convencido, seguís trabajando, a los dos días te das cuenta de que faltaba el commit del login, abrís el reflog, encontrás la línea con el mensaje, creás la rama de rescate y todo vuelve a estar ahí, siempre que hayas commiteado y no hayan pasado los 30 días. En elegir entre Jenkins y GitHub Actions profundizamos sobre esto.

¿Qué hábitos evitan perder trabajo en git?

Cinco hábitos del post reducen el costo de los errores:

• Commiteá seguido. Un commit es un punto de seguridad, y el trabajo sin commitear es el más difícil de recuperar.
• Mirá antes de borrar. Corré git status y git diff antes de reset --hard o restore.
• Hacé una rama de respaldo. Antes de algo riesgoso, git branch backup.
• Evitá el force push en ramas compartidas. Si no hay otra, --force-with-lease.
• Leé el comando primero. git help <comando> responde más rápido que un foro.

Una verificación que sumamos como propuesta editorial: después de cada arreglo, corré git status y git log --oneline y compará con lo que esperabas ver. Si falta un commit, mirá el reflog antes de escribir el próximo comando. La fuente recomienda frenar y consultar git status y git reflog; el cotejo del log es idea nuestra y no lo probamos con mediciones.

¿Cuáles son los errores más comunes al deshacer cambios en git?

• Usar amend después del push. Cambia el historial publicado y le rompe la copia a tu equipo. Corrección: git revert.
• Correr reset --hard sin mirar el estado. Se lleva los cambios sin commitear. Corrección: git status, git diff y un commit o stash antes.
• Esperar que el reflog recupere cambios sin commitear. Solo registra commits. Corrección: commitear seguido.
• Confundir restore con restore --staged. Uno descarta cambios para siempre, el otro solo los baja del staging. Corrección: revisá si aparece --staged antes de dar Enter.
• Tomar el “arreglo rápido” de forzar el push. Puede pisar trabajo ajeno. Corrección: --force-with-lease, y solo si no queda otra.

Preguntas Frecuentes

¿Cómo deshago el último commit en git sin perder mis cambios?

Corré git reset --soft HEAD~1: elimina el último commit y deja tus cambios en staging. Si preferís que queden sin staging, usá git reset HEAD~1, que aplica --mixed por defecto.

¿Cuál es la diferencia entre git reset –soft, –mixed y –hard?

Los tres eliminan el commit y difieren en tus cambios: --soft los deja en staging, --mixed los deja sin staging y --hard los borra. Solo --hard destruye trabajo.

¿Cómo deshago un commit que ya subí al remoto?

Usá git revert <hash>, que crea un commit nuevo con el efecto opuesto. El historial compartido no se reescribe, así que nadie del equipo pierde trabajo.

¿Cómo recupero una rama borrada en git?

Buscá el último commit de la rama en git reflog y creá una rama desde ese hash con git branch recovered <hash>. Tiene que ser un trabajo commiteado y dentro del plazo de expiración del reflog.

¿Cómo paso un commit de main a otra rama en git?

Corré git branch feature, después git reset --hard origin/main y por último git switch feature. Antes commiteá o hacé stash de lo pendiente, porque el reset duro borra cambios sin commitear.

Conclusión

Casi todos los casos se resuelven con cuatro comandos: reset --soft para lo local, revert para lo publicado, restore para archivos y reflog para lo que parece perdido. La frontera es una sola: lo commiteado se rescata y lo que no, no. Guardá una rama de respaldo antes de cualquier comando destructivo, y si algo sale mal, frená y consultá git status y git reflog antes del siguiente paso. Tomá los plazos de 30 y 90 días como referencia de la documentación y no como garantía.

Fuentes

• Git – git-reflog Documentation – documentación oficial del comando, subcomandos y plazos de expiración
• How to Undo Common Git Mistakes Without Panic – guía en dev.to con siete errores comunes y sus arreglos