Deshacer el último commit de git sin perder los cambios

git reset --soft HEAD~1 elimina el commit y deja todos los cambios en el índice, exactamente como estaban un momento antes de hacer commit. Esa es la respuesta para el caso común. En qué caso estás importa más que la opción que uses.

1. Aún no hiciste push — deshacer el commit, mantener el trabajo en el índice

$ clai deshace mi último commit pero mantén los cambios en el índice→ git reset --soft HEAD~1$ git status --shortM  f.txt

El commit desaparece del log, los archivos quedan intactos, todo sigue en el índice. Corrige el mensaje o añade el archivo que olvidaste, y vuelve a hacer commit.

2. Mantener los cambios pero sacarlos del índice

$ clai deshace el último commit y también saca los cambios del índice→ git reset HEAD~1

--mixed es el modo por defecto. Igual que soft, un paso más allá: los archivos se quedan en disco, el índice se vacía. Úsalo cuando quieras repartir el trabajo en distintos commits.

3. Descartar el trabajo por completo

$ clai elimina mi último commit y todos sus cambios de forma permanente→ git reset --hard HEAD~1⚠ DANGER — uncommitted changes in the working tree are destroyed

--hard es el único de los tres que pierde trabajo. El contenido comiteado se puede recuperar con reflog; lo que habías modificado pero no comiteado, no.

4. Ya hiciste push — revert en vez de reset

$ clai deshace el commit que ya subí, sin reescribir el historial→ git revert HEAD

revert crea un commit nuevo que deshace el anterior. El historial queda intacto, así que nadie que ya haya hecho pull tiene que hacer nada. En una rama compartida, esta es la única respuesta correcta.

5. Solo corregir el mensaje

$ clai cambia el mensaje de mi último commit→ git commit --amend -m "Fix cache invalidation on write path"

Si no hay nada en el índice, --amend reescribe solo el mensaje. Si hay algo en el índice, también lo incorpora al commit anterior — útil, pero fácil de hacer sin querer.

6. Te equivocaste — recupéralo

$ clai muéstrame dónde estaba HEAD antes de ese reset→ git reflog4d2e830 HEAD@{0}: reset: moving to HEAD~1dc4fa62 HEAD@{1}: commit: second4d2e830 HEAD@{2}: commit (initial): first$ git reset --hard dc4fa62

reflog recuerda cada posición que ha tenido HEAD durante 90 días por defecto. Un reset --hard sobre un commit perdido lo trae de vuelta exactamente como estaba.

Trampas habituales

• Nunca hagas force-push de un reset a una rama compartida. Reescribir un historial que otros ya han hecho pull rompe sus clones. Para eso existe revert.
• HEAD~1 y HEAD^ son lo mismo aquí — un commit atrás. Solo difieren en los merge commits, donde HEAD^2 significa el segundo padre.
• --amend después de hacer push también reescribe el historial. Crea un nuevo objeto de commit con un hash nuevo, así que aplica la misma regla.

Preguntas relacionadas

¿Cómo deshago los últimos tres commits pero mantengo todos los cambios? git reset --soft HEAD~3 — todo lo de esos commits termina en el índice junto.

¿Reset elimina el commit para siempre? No de inmediato. Se vuelve inalcanzable y reflog sigue apuntando a él unos 90 días, hasta que corre la recolección de basura.

¿Reset o revert en una rama que nadie más usa? Reset. Es más limpio. Revert en cuanto alguien más pueda haber hecho pull.

Ver también

• Tareas de git dichas en voz alta: «muéstrame los commits que no he subido»
• SAFE, CAUTION, DANGER: cómo CliAI clasifica lo que está por ejecutarse
• Día 1 de onboarding: cómo CliAI reemplaza el «pregúntale al senior en Slack»

CliAI marca reset --hard como DANGER y pide confirmación escrita — el único comando de git que realmente pierde trabajo. Instálalo en una línea.