Un recorrido del tutorial Deshacer un commit: por qué el último commit está roto y cómo git reset --soft te permite arreglarlo sin perder trabajo.
Este escenario comienza en un proyecto de portfolio donde el último commit está sutilmente roto. Vas a leer la historia, deshacer ese commit conservando tus cambios y volver a commitearlo correctamente. Esto es lo que pasa en cada paso y por qué.
La situación
El proyecto tiene dos commits. El último, "Add header section", añadió una cabecera de navegación a index.html. El CSS correspondiente para esa cabecera se escribió en style.css, pero nunca se preparó: sigue en el árbol de trabajo como cambio no commiteado.
Así que el commit está incompleto. El sitio commiteado tiene el marcado de la cabecera apuntando a estilos que no se guardaron. Quien haga checkout de ese commit verá una cabecera rota.
Empieza ejecutando git log --oneline y git status. El log muestra el commit "Add header section"; el status muestra style.css como modificado pero no preparado. Ese desajuste es todo el problema.
La solución, paso a paso
Inspeccionar lo que se commiteó
git log confirma el último commit, y git status muestra que style.css sigue modificado en el árbol de trabajo. Ya sabes que el commit capturó index.html pero no style.css.
Deshacer el commit, conservar los cambios
git reset --soft HEAD~1
Esto retrocede el puntero de la rama un commit. El cambio en index.html que estaba en el commit vuelve al área de preparación, listo para commitearse de nuevo. Nada en tus archivos se borra.
Preparar todo esta vez
git add index.html style.css
Ahora el marcado y sus estilos están preparados juntos, para que el próximo commit sea completo.
Recommitear el cambio completo
git commit -m "Add header section"
La historia vuelve a tener un único commit "Add header section", pero esta vez incluye style.css. El sitio está íntegro.
Por qué --soft es el modo correcto aquí
git reset tiene tres modos, y la diferencia solo está en dónde aterrizan tus cambios:
--soft mueve HEAD atrás y mantiene los cambios preparados. Ideal aquí, porque quieres recommitear de inmediato.--mixed (el predeterminado) conserva los cambios pero no preparados, en el árbol de trabajo.--hard descarta los cambios por completo.
Aquí git reset --hard HEAD~1 borraría el trabajo de la cabecera junto con el commit. Reserva --hard para cuando de verdad quieras que los cambios desaparezcan.
Si llegas a ejecutar --hard por accidente, el commit suele ser todavía recuperable con git reflog, que lista todas las posiciones por las que ha pasado HEAD. El tutorial "Recover Lost Commits" cubre ese flujo.
Un matiz: commits compartidos
Todo lo anterior reescribe la historia, lo cual es perfectamente seguro para un commit que solo existe en tu máquina. Una vez que un commit ha sido pusheado y recogido por otros, reescribirlo obliga a todos a lidiar con una rama divergida. En una rama compartida, deshaz el cambio con un nuevo commit:
git revert HEAD
El comando correcto depende de qué quieras conservar. Este escenario usó --soft; aquí tienes el conjunto completo:
- Deshacer el último commit, mantener los cambios preparados —
git reset --soft HEAD~1
- Deshacer el último commit, mantener los cambios sin preparar —
git reset HEAD~1 (el modo por defecto, --mixed)
- Deshacer el último commit y descartar sus cambios —
git reset --hard HEAD~1
- Deshacer los últimos N commits, conservar el trabajo —
git reset --soft HEAD~N
- Cambiar el mensaje o el contenido del último commit en el sitio —
git commit --amend
- Deshacer un commit que ya ha sido pusheado —
git revert <commit>
reset reescribe la historia y sirve para commits que solo existen en tu máquina; revert añade un nuevo commit que cancela uno antiguo y es la opción segura en una rama que otros han recogido. Prueba cada uno aquí para que la diferencia entre conservar, quitar de preparación y descartar tu trabajo se vuelva algo natural.