Cometer un error en Git es más normal de lo que parece. Quizá has hecho commit demasiado pronto, has olvidado añadir un archivo importante o simplemente quieres reescribir el mensaje antes de compartirlo con tu equipo. La buena noticia es que puedes deshacer el último commit sin perder tu trabajo, siempre que elijas la estrategia adecuada.
Este escenario es especialmente útil cuando todavía no has enviado los cambios al remoto o cuando quieres mantener los archivos modificados en tu entorno local. En esta guía veremos las opciones más seguras para deshacer el último commit, qué hace cada comando y cuándo conviene usarlo.
Qué significa “deshacer” un commit en Git
En Git, un commit no solo guarda la versión de los archivos; también crea un punto en el historial que apunta a un estado concreto del repositorio. Por eso, “deshacer” puede significar varias cosas: mover la referencia del branch hacia atrás, conservar los cambios en el área de trabajo o limpiar también el índice.
Si todavía estás empezando con el flujo básico, quizá te interese repasar primero cómo funciona el historial en cómo ver el historial de cambios con git log y cómo inspeccionar diferencias con cómo comparar cambios con git diff. Entender eso ayuda a tomar la decisión correcta antes de tocar el historial.
Las tres zonas que debes tener claras
Antes de aplicar cualquier comando, conviene recordar la relación entre:
Repositorio o historial comprometido, índice o staging area y directorio de trabajo o working tree.
La clave está en decidir dónde quieres conservar los cambios después de deshacer el commit. No siempre necesitas borrar nada; a veces solo quieres “despublicar” el commit para seguir editando.
Opción 1: usar git reset –soft para conservar todo
Si lo que quieres es deshacer el último commit pero mantener los cambios listos para volver a commitear, la opción más cómoda suele ser git reset –soft HEAD~1.
# Deshace el último commit
# Mantiene los cambios en el staging area
git reset --soft HEAD~1Este comando mueve la rama un commit hacia atrás, pero deja los archivos tal como estaban en el área de preparación. Es ideal si olvidaste incluir algo o si quieres ajustar el mensaje del commit sin rehacer el trabajo.
Por ejemplo, si el commit contiene una versión incompleta de una funcionalidad, puedes revertir el último commit, añadir los archivos que faltaban y crear uno nuevo con más sentido. Si necesitas repasar el concepto de staging, puedes verlo en cómo añadir archivos al repositorio con git add.
Cuándo usarlo
Usa reset –soft cuando quieras conservar exactamente lo que ya habías preparado. Es muy útil para corregir un commit demasiado rápido o para reorganizar el mensaje antes de compartirlo.
Opción 2: usar git reset –mixed si quieres mantener los cambios, pero no el staging
Si deseas deshacer el último commit y, además, sacar los cambios del área de staging para revisarlos con calma, entonces la opción más adecuada es git reset –mixed HEAD~1. De hecho, es el comportamiento por defecto de git reset si no indicas modo.
# Deshace el último commit
# Conserva los cambios en el directorio de trabajo
# Quita los archivos del staging area
git reset --mixed HEAD~1Con este enfoque, los archivos siguen modificados en tu carpeta, pero ya no están listos para commit. Esto te permite revisar línea por línea, aplicar más cambios y volver a ejecutar git add cuando estés conforme.
Si tu objetivo es rehacer un commit con mayor limpieza, esta opción suele resultar más intuitiva que la versión soft, especialmente si prefieres volver a seleccionar qué entra y qué no en el siguiente commit.
Opción 3: usar git reset –hard solo cuando quieras descartar todo
Existe una tercera variante, git reset –hard HEAD~1, pero aquí hay que tener mucha precaución. Esta opción elimina el commit y también descarta los cambios del staging y del directorio de trabajo.
En otras palabras: no la uses si quieres conservar tu trabajo. Solo es apropiada cuando estás completamente seguro de que ese último commit y sus cambios ya no sirven. Si tienes dudas, no es la herramienta correcta.
# Elimina el último commit y borra los cambios locales
# Úsalo únicamente si estás seguro de perder ese trabajo
git reset --hard HEAD~1Si alguna vez necesitas recuperar algo que parecía perdido, puedes apoyarte en herramientas como cómo recuperar commits borrados con git reflog. Aun así, lo ideal es no depender de la recuperación cuando puedes evitar el problema desde el principio.
Qué pasa si el commit ya se ha subido al remoto
Aquí cambia el enfoque. Si el último commit ya fue enviado con git push, reescribir el historial puede crear conflictos con otras personas que trabajen sobre la misma rama. En ese caso, normalmente es más seguro usar git revert para añadir un commit nuevo que deshaga el anterior.
Si todavía no dominas el flujo entre repositorio local y remoto, puede ayudarte repasar cómo subir cambios al repositorio con git push y cómo descargar cambios del repositorio con git pull. Entender la sincronización evita sorpresas cuando trabajas en equipo.
Regla práctica sencilla
Haz reset si el commit solo existe en tu copia local y quieres reescribirlo. Usa revert si el commit ya está compartido y necesitas mantener un historial seguro para otras personas.
Eso no significa que una opción sea “mejor” que la otra en abstracto; significa que tienen objetivos distintos. Si quieres profundizar en el enfoque inverso, revisa cómo revertir un commit con git revert.
Ejemplos prácticos de uso
Imagina que hiciste un commit antes de añadir una validación importante. Si todavía no lo has subido, podrías hacer:
# Volver un commit atrás y conservar los cambios en staging
git reset --soft HEAD~1
# Añadir el archivo corregido
git add validar-formulario.js
# Crear un nuevo commit con el contenido correcto
git commit -m "Añade validación completa al formulario"Otro caso común: haces un commit, pero luego te das cuenta de que querías revisar mejor los cambios antes de elegir qué incluir. En ese escenario, –mixed te deja los archivos modificados para inspeccionarlos con calma.
También puede ocurrir que un commit contenga cambios mezclados de varias tareas. Entonces deshacer el commit con cuidado te ayuda a separar responsabilidades, algo muy útil cuando trabajas con ramas limpias y mensajes precisos. Si estás organizando el trabajo por líneas de desarrollo, quizá te interese recordar cómo funcionan las ramas en qué son las ramas en Git y cómo funcionan.
Errores comunes al deshacer el último commit
Uno de los errores más frecuentes es confundir “deshacer el commit” con “borrar los cambios”. No siempre son lo mismo. Por eso conviene verificar antes el estado del repositorio con cómo consultar el estado del repositorio con git status.
Otro error habitual es ejecutar reset –hard por inercia. Ese comando es potente, pero también destructivo. Si trabajas en un entorno compartido o tienes dudas sobre el alcance, pausa y elige una alternativa menos agresiva.
Tampoco conviene reescribir historial si ya has compartido la rama con varias personas sin avisar. En equipos, la coordinación importa tanto como la técnica. Una buena práctica es acordar cuándo se permite reescribir commits locales y cuándo se debe optar por commits de corrección.
Consejo final para trabajar con más seguridad
Si tu intención es aprender Git de forma progresiva, una buena estrategia es tratar cada acción como parte de un flujo: revisar, decidir, aplicar y verificar. Primero mira el estado, luego el historial y finalmente el tipo de deshacer que encaja con tu objetivo.
Cuando tengas dudas, una revisión rápida con git diff y git status suele darte la respuesta correcta antes de tocar el historial. Esa pequeña pausa marca la diferencia entre arreglar un commit y complicarte la rama.
En resumen, deshacer el último commit sin perder cambios es totalmente posible, pero la clave está en elegir entre soft, mixed o revert según el contexto. Cuanto más claro tengas qué quieres conservar, más sencillo será recuperar el control del repositorio.
Fuentes y lecturas recomendadas
Documentación oficial de git reset
Documentación oficial de git revert
Documentación oficial de GitHub
Deja una respuesta