La lección anterior dejó el catálogo montado y resolvió los casos de un minuto. Ahora toca el comando que aparecía en media docena de filas de aquella tabla y que llevamos cinco módulos prometiendo: git reset.

Es probablemente el comando peor entendido de Git. Tiene tres modos que hacen cosas distintas, dos formas de invocarlo que se comportan de manera completamente diferente, y una fama de peligroso que es merecida solo en uno de sus usos. La confusión no es casual: reset hace dos trabajos que en otros sistemas serían dos comandos distintos.

Esta lección lo desmonta pieza a pieza y después lo pone en contexto. Porque reset no es la respuesta a "quiero deshacer algo": es una de las respuestas, y elegir la equivocada es lo que convierte un cambio no deseado en un problema para todo el equipo. Al final tendrás una tabla de decisión que responde a la única pregunta que importa: ¿dónde está lo que quiero deshacer?

Y una advertencia que vale para toda la lección: aquí aparece el único comando de Git que destruye de verdad, sin red de seguridad posible. No es reset. Es git clean.

1. Las tres zonas, otra vez
2. git reset mueve la rama: la idea central
3. Los tres modos: --soft, --mixed, --hard
4. Casos ordenados por lo que quieres deshacer
5. git reset <commit> -- <ruta>: la otra forma
6. git restore: el comando moderno para el trabajo diario
7. git clean: el que sí destruye
8. ORIG_HEAD: la red de seguridad inmediata
9. La tabla de decisión

Todo reset se entiende en cuanto se recuperan las tres zonas de la lección 01-03. Merece la pena tenerlas delante:

Tres fotos del proyecto que pueden coincidir o no:

Cuando git status dice "Changes to be committed", está comparando índice con HEAD. Cuando dice "Changes not staged for commit", compara directorio de trabajo con índice. Con eso claro, reset deja de ser un misterio: cada modo decide hasta cuál de esas tres zonas llega el cambio.

Antes de los modos, la operación básica. Esto es lo que hace git reset <commit> siempre, en los tres modos:

Mueve la rama actual para que apunte a <commit>. Y como HEAD apunta a la rama, HEAD se mueve con ella.

No borra commits. No modifica commits. Reescribe un fichero de 41 bytes (lección 03-01).

b52c9d1 y 7d3a8f4 siguen existiendo íntegros en .git/objects. Lo que ha cambiado es que GT-241 ya no los alcanza, así que git log no los muestra. Recuperarlos es trivial mientras el reflog los recuerde (lección 09-04).

De aquí salen las dos consecuencias que hay que interiorizar:

1. reset es seguro sobre trabajo local. Aunque te equivoques, los commits siguen ahí.

2. reset es peligroso sobre trabajo publicado. Porque mover la rama hacia atrás y volver a avanzar produce una historia distinta de la que otros tienen. El push será rechazado (non-fast-forward), y forzarlo destruiría el trabajo de los demás. Es la regla de oro de la lección 05-01, y su tratamiento completo es la lección 09-03.

Un tercer matiz que casi nadie conoce y que evita muchos sustos:

Sin argumento de commit, reset usa HEAD, es decir, no mueve nada. Solo actúa sobre el índice. Por eso git reset a secas es completamente inofensivo: vacía el área de preparación y deja tus ficheros intactos.

La diferencia entre los tres es hasta dónde propaga el cambio.

Visualmente, sobre las tres zonas:

El commit ha desaparecido de la rama, y todo su contenido está preparado, listo para volver a confirmarse. Los M y A con la letra en la primera columna significan "en el índice".

Es el modo de "quiero rehacer este commit". De hecho, es exactamente lo que hace git commit --amend por dentro.

Ahora la letra está en la segunda columna: los cambios están en el directorio de trabajo, sin preparar. Y estilos.css, que era nuevo, ha vuelto a ser un fichero sin seguimiento.

Es el modo de "quiero rehacer este commit y volver a elegir qué entra". Es el que usaste en la lección 05-02 para dividir un commit en dos.

Todo limpio, como si aquel commit nunca hubiera existido. Y aquí está el peligro, que conviene enunciar con precisión:

--hard no destruye los commits (siguen en la base de datos). Destruye los cambios sin confirmar que hubiera en ese momento en el índice y en el directorio de trabajo.

Eso es lo que no tiene vuelta atrás, porque nunca estuvo en .git/objects (lección 09-01, tabla del apartado 1).

Una excepción importante y tranquilizadora: --hard no toca los ficheros sin seguimiento. Si tenías un notas.txt que nunca añadiste, sigue ahí. Lo que se lleva por delante son las modificaciones de ficheros seguidos.

La fila del --hard es la que hay que memorizar: se lleva dos cosas a la vez, el commit y tu trabajo en curso. Y solo una de las dos se puede recuperar.

Existen y en dos situaciones son exactamente lo que quieres:

--keep es un --hard educado: mueve la rama y actualiza los ficheros que difieren, pero aborta si eso pisaría un cambio local. Es la opción sensata cuando quieres retroceder y no estás seguro de tener todo confirmado:

Ese error, aquí, es una buena noticia: te ha salvado.

--merge es parecido pero intenta fusionar los cambios locales en el destino. Se usa sobre todo para abortar una fusión a mano.

Regla práctica: cuando tengas la tentación de escribir --hard y no estés seguro, escribe --keep. Si funciona, no había nada que perder; si falla, acabas de evitar el problema.

Este es el recetario. Está ordenado de menor a mayor alcance.

Ana ha estado probando cosas en estilos.css y quiere volver a como estaba.

Esto sí destruye, y sin red: las modificaciones no confirmadas no están en ninguna parte. Git ni siquiera pregunta.

Bruno ha hecho git add . y ha metido sin querer notas-personales.md.

No has perdido nada: el fichero sigue modificado en el directorio de trabajo, solo deja de estar preparado.

Fíjate en la asimetría, que es la fuente de confusión número uno:

git restore sin opciones actúa sobre el directorio de trabajo. Con --staged, sobre el índice. Es lo contrario de lo que mucha gente asume, y es la razón de que git restore merezca su propio apartado (el 6).

El caso más frecuente de todos. Carla ha confirmado y se ha dado cuenta de que el commit mezcla dos cosas.

No has perdido nada. El commit ya no está en la rama, pero todo su contenido está preparado. Ahora puede rehacerlo:

Si además quiere volver a elegir qué entra en cada commit, --mixed y git add -p (lección 02-04):

Ese es el flujo completo de "he mezclado dos cosas en un commit", y es el que se usa a diario.

No hace falta reset para esto. --amend sustituye el último commit (lección 02-04), y con -m ni siquiera abre el editor:

Recuerda que el hash cambia: si estaba publicado, esto reescribe historial.

Tres commits fuera de la rama. Antes de ejecutarlo, dos costumbres que cuestan cinco segundos:

Con git branch respaldo-GT-241, el --hard deja de ser irreversible en ningún sentido: los commits siguen alcanzables desde el respaldo. Es el mismo patrón que en la lección 09-01, apartado 5.2, y el que se generaliza en la 09-04.

Y si ya lo hiciste sin respaldo: tampoco pasa nada, mientras no fueran cambios sin confirmar.

Es el "descarta todo lo mío y déjame como el servidor". Útil cuando tu copia local se ha enredado sin remedio y sabes que no hay nada tuyo que salvar.

Comprueba antes qué vas a tirar:

Si la primera lista no está vacía, no ejecutes el --hard sin crear antes una rama de respaldo.

Aquí reset no es la respuesta. Reescribir una rama publicada obliga a forzar el push y destruye el trabajo de quien tenga la versión anterior.

La respuesta es git revert (lección 05-06): crea un commit nuevo con el cambio inverso, no reescribe nada, no hace falta forzar, y queda constancia.

La única excepción: una rama publicada que es exclusivamente tuya (tu rama de trabajo GT-241, que nadie más usa). Ahí sí puedes reescribir y forzar con --force-with-lease, y eso es la lección 09-03.

Aquí está la fuente principal de confusión con reset, y merece un apartado propio.

Cuando añades una ruta, git reset hace algo completamente distinto:

git reset <commit> -- <ruta> NO mueve la rama. Copia el estado de <ruta> en <commit> al índice, y deja el directorio de trabajo intacto.

Por qué no puede mover la rama: mover HEAD a otro commit es una operación sobre el repositorio entero. No existe "mover la rama solo para un fichero". Así que cuando das una ruta, Git entiende que quieres la otra operación: rellenar el índice desde un commit.

Consecuencia directa: git reset <commit> -- <ruta> no acepta --hard.

Precisamente porque el modo --hard implica tocar el directorio de trabajo, y esta forma nunca lo hace.

Es la forma de preparar el contenido antiguo de un fichero, típicamente para deshacer solo una parte de un commit:

El índice tiene ahora la versión anterior de estilos.css, preparada. Un git commit crea un commit que deshace solo esa parte.

Y si además quieres que el fichero en disco cambie, la forma moderna y mucho más clara es git restore:

Retomando la lección 08-03:

git rm --cached quita el fichero del índice (deja de tener seguimiento) pero lo conserva en disco. Es la operación que hay que hacer cuando algo entró en el repositorio y luego lo añadiste al .gitignore. Es una prima hermana de git reset -- <ruta>, pero para dejar de seguir el fichero en lugar de restaurar su contenido.

Git 2.23 partió el viejo git checkout en dos comandos con nombres honestos: git switch para las ramas (lección 03-02) y git restore para los ficheros. Es la herramienta que deberías usar a diario, dejando reset para lo que de verdad implica mover la rama.

La tabla de equivalencias con lo antiguo, porque vas a ver las dos formas en documentación y en respuestas de foro:

git restore -p merece una mención aparte. Es el hermano de git add -p: te enseña cada trozo del diff y te pregunta si quieres descartarlo. Es la forma quirúrgica de deshacer parte de un cambio sin perder el resto, y evita el "voy a descartar todo y rehacerlo".

Perfecto para quitar los console.log de depuración conservando el trabajo real.

Todo lo anterior tiene red de seguridad en algún grado. Este comando no tiene ninguna, y por eso merece el tono más serio de la lección.

git clean borra ficheros sin seguimiento. Y un fichero sin seguimiento nunca ha pasado por .git/objects: no hay commit, no hay blob, no hay reflog, no hay fsck que valga. Cuando git clean lo borra, está borrado, igual que con rm.

-n (o --dry-run) no borra nada: solo lista. Léelo entero. Si en esa lista aparece algo que te importa, no ejecutes el comando real.

Esta costumbre no es opcional. Es la diferencia entre limpiar el proyecto y perder el fichero de configuración local que llevas seis meses manteniendo a mano.

Los usos habituales:

-x es la que hay que mirar dos veces. Borra lo que .gitignore protege, y ahí suele estar precisamente lo que no está en el repositorio pero sí te importa: .env con la configuración local, credenciales de desarrollo, bases de datos de prueba.

La opción 4 (ask each) pregunta uno por uno. Cuando hay muchos ficheros y solo algunos sobran, es la forma correcta.

La combinación que circula por internet como "dejarlo todo limpio":

Eso deja el directorio exactamente como un clon recién hecho de ese commit. Y se lleva por delante, sin preguntar y sin recuperación posible:

• Todos los cambios sin confirmar de ficheros seguidos.
• Todos los ficheros nuevos que no habías añadido.
• Todo lo ignorado: .env, node_modules/, configuraciones locales, bases de datos de prueba.

Es un comando legítimo —en CI, en un contenedor, en un repositorio de usar y tirar— y una catástrofe en la máquina de alguien que llevaba dos horas trabajando. Nunca lo pegues sin haber ejecutado antes git clean -ndx y leído la lista.

git stash -u (lección 05-04) guarda también los ficheros sin seguimiento, y los guarda como objetos de Git. Con eso, lo que ibas a borrar pasa a estar en la base de datos y, por tanto, deja de ser irrecuperable. Cuesta un segundo.

Antes de una operación que mueve HEAD de forma sustancial —reset, merge, rebase, pull—, Git guarda la posición anterior en una referencia especial:

Así que el "deshacer" inmediato de un reset es:

O, siguiendo el patrón seguro:

Dos advertencias sobre ORIG_HEAD:

• Solo guarda una posición, la de la última operación. Si haces dos reset seguidos, la primera se pierde. Para eso está el reflog, que guarda todo el historial de movimientos (lección 09-04).
• No recupera cambios sin confirmar. ORIG_HEAD es un hash de commit: devuelve la rama a su sitio, no tu trabajo en curso.

Es la red de seguridad de los treinta segundos siguientes. Para todo lo demás, la 09-04.

La pregunta correcta no es "¿qué comando uso para deshacer?", sino "¿dónde está lo que quiero deshacer?". Con esa respuesta, el comando es inmediato.

Y en forma de tabla, que es como se consulta en el momento:

La fila que gobierna todas las demás es la de "¿está publicado?". Si la respuesta es sí y la rama es compartida, reset sale de la lista y la única herramienta correcta es revert.

Error 1: creer que reset --hard borra commits. No los borra: mueve la rama. Los commits siguen en .git/objects y el reflog los encuentra (09-04). Lo que sí destruye son los cambios sin confirmar.

Error 2: usar --hard cuando bastaba --soft. Si solo querías rehacer el commit, --soft conserva todo preparado. --hard se lleva además tu trabajo en curso.

Error 3: confundir git restore <f> con git restore --staged <f>. El primero destruye el cambio en disco; el segundo solo lo saca del índice y no pierde nada. Son casi opuestos.

Error 4: esperar que git reset <commit> -- <ruta> mueva la rama. No lo hace nunca, y por eso --hard con rutas da error. Es otra operación con el mismo nombre.

Error 5: ejecutar git clean -fdx copiado de internet. Borra .env, configuraciones locales y todo lo ignorado, sin recuperación posible. -n primero, siempre.

Error 6: hacer reset en una rama compartida y forzar el push. Destruye el trabajo de quien tuviera los commits. En lo publicado, revert (05-06).

Error 7: usar git reset --hard origin/main sin comprobar qué hay tuyo por delante. git log --oneline origin/main..HEAD cuesta un segundo y te dice exactamente qué vas a tirar.

Error 8: olvidar que --hard respeta los ficheros sin seguimiento. No es un error grave, pero explica el "he hecho reset --hard y esto sigue aquí": no tenía seguimiento.

Consejo 1: cuando dudes entre --hard y no hacer nada, usa --keep. Hace lo mismo, pero aborta en lugar de pisar cambios locales.

Consejo 2: git branch respaldo-<algo> antes de cualquier reset --hard. Cuesta dos segundos y convierte la operación en trivialmente reversible.

Consejo 3: usa git restore y git switch en lugar de git checkout. Los nombres dicen lo que hacen y evitan errores por confusión.

Consejo 4: git restore -p para quitar los console.log. Quirúrgico, y conserva el resto del trabajo.

Consejo 5: git stash push -u antes de cualquier limpieza. Convierte lo irrecuperable en recuperable por un segundo de esfuerzo.

Consejo 6: recuerda ORIG_HEAD. El deshacer inmediato de un reset, merge, rebase o pull que acabas de lamentar.

1. Crea un repositorio con app.js y tres commits. En el tercero, añade también estilos.css.
2. Modifica app.js sin confirmar y crea un fichero nuevo notas.txt sin añadirlo.
3. Ejecuta git reset --soft HEAD~1 y anota la salida de git status --short y git log --oneline -1.
4. Deshaz con git reset --hard ORIG_HEAD... y observa qué ha pasado con tu modificación de app.js. Explícalo.
5. Repite el experimento completo con --mixed y con --hard, y rellena una tabla con tres columnas: log -1, cambio sin confirmar en app.js, y notas.txt.
6. Explica por qué notas.txt sobrevive incluso a --hard.

1. Sobre un repositorio con cuatro commits, donde el tercero modificó app.js, estilos.css e index.html, intenta git reset --hard HEAD~1 -- app.js y explica el error.
2. Usa git reset HEAD~2 -- estilos.css y comprueba con git status, git diff y git diff --cached en qué zona ha quedado el cambio.
3. Confirma. Comprueba que has deshecho solo la parte de estilos.css del tercer commit y que el resto sigue en el proyecto.
4. Consigue el mismo resultado con git restore --source=... --staged --worktree y compara el estado del directorio de trabajo en ambos casos.

1. En un repositorio de pruebas, crea tres situaciones a la vez: un commit sin publicar, un cambio preparado con git add, y un cambio solo en disco.
2. Ejecuta git reset --hard HEAD~1.
3. Recupera el commit usando el reflog.
4. Intenta recuperar el cambio preparado con git fsck --lost-found y git cat-file -p.
5. Intenta recuperar el cambio que estaba solo en disco. Documenta por qué no es posible.
6. Repite todo el ejercicio ejecutando antes git stash push -u y explica qué cambia.

Solución 1:

El commit ha salido de la rama y su contenido está preparado (M y A en la primera columna). Y aquí hay un detalle fino: app.js aparece una sola vez porque el índice contiene tanto lo del commit deshecho como tu modificación sin confirmar aún fuera... en realidad la modificación de app.js sigue en el directorio de trabajo, y el índice tiene la versión del commit deshecho. Compruébalo:

Nada se ha perdido: las dos capas están intactas y separadas.

La rama ha vuelto a su sitio, pero la modificación de app.js ha desaparecido: --hard la ha sobrescrito. ORIG_HEAD devuelve la posición de la rama, no tu trabajo en curso. Es exactamente la advertencia del apartado 8.

notas.txt no está en el índice: Git no lo sigue. reset opera sobre HEAD, el índice y los ficheros que Git conoce; un fichero sin seguimiento le es invisible. Para borrarlo hace falta git clean (apartado 7).

Solución 2:

Con una ruta, reset nunca toca el directorio de trabajo ni mueve la rama; --hard implica ambas cosas, así que es contradictorio. Git lo rechaza en lugar de hacer algo a medias.

Clave: el fichero en disco sigue siendo v3. Solo el índice tiene v1. Por eso git diff (trabajo vs índice) muestra el cambio inverso. Y la rama no se ha movido:

app.js conserva v4, index.html conserva v3 (lo que aportó c3), y solo estilos.css ha vuelto atrás. Se ha deshecho una tercera parte de un commit.

Aunque atención: el fichero en disco seguía siendo v3 al confirmar. El commit dice v1 y el disco dice v3, así que ahora hay una modificación pendiente. Esa asimetría es justo lo que evita restore:

Índice y directorio de trabajo coinciden. Esa es la diferencia práctica: reset -- <ruta> solo prepara; restore --staged --worktree prepara y escribe en disco. Para el uso diario, restore es más predecible.

Solución 3:

Todo fuera: el commit, el fichero preparado y la modificación en disco.

Recuperado íntegro.

El git add lo salvó. Al preparar el fichero, Git creó el blob y lo escribió en .git/objects. El reset --hard quitó la referencia desde el índice, pero el objeto se quedó.

Solo hay un objeto colgante, el del add. La línea CAMBIO SOLO EN DISCO no existe en ninguna parte de .git. Nunca se calculó su hash, nunca se comprimió, nunca se escribió. Git no puede recuperar algo de lo que jamás tuvo noticia. Las únicas vías reales serían el historial local de tu editor (VS Code, IntelliJ y Vim con undofile lo guardan) o una copia de seguridad del sistema de ficheros.

Todo intacto, incluido el fichero sin seguimiento gracias a -u. El stash convirtió las tres capas en commits ocultos dentro de la base de datos, y por tanto en algo recuperable incluso si se hubiera borrado el stash (lección 09-04).

Un segundo de git stash push -u compra la diferencia entre "he perdido dos horas" y "no ha pasado nada".

reset deja de dar miedo en cuanto se entiende que hace dos cosas con el mismo nombre.

• git reset <commit> mueve la rama. No borra commits: reescribe un fichero de 41 bytes. Los commits que dejan de ser alcanzables siguen íntegros en la base de datos.
• Los tres modos se distinguen por hasta dónde llegan: --soft solo mueve HEAD; --mixed (por defecto) además reescribe el índice; --hard además sobrescribe el directorio de trabajo. Solo --hard destruye algo, y lo que destruye son los cambios sin confirmar, no los commits. Los ficheros sin seguimiento no los toca.
• --keep es el --hard prudente: aborta en lugar de pisar tu trabajo local.
• git reset <commit> -- <ruta> es otra operación: nunca mueve la rama, nunca toca el disco, solo rellena el índice. Por eso --hard con rutas es un error.
• Para el trabajo diario, git restore: --staged para despreparar (no pierde nada), sin opciones para descartar en disco (destruye), --source para traer de otro commit y -p para hacerlo trozo a trozo.
• git clean es el único comando de este módulo sin red de seguridad, porque lo que nunca se confirmó no está en .git/objects. -n antes que -f, siempre; -x merece leerse dos veces; git stash push -u lo convierte todo en recuperable.
• ORIG_HEAD deshace el último reset, merge, rebase o pull. Solo guarda una posición.
• Y la decisión, en una pregunta: ¿está publicado? Si no, reset, --amend o rebase -i. Si sí y la rama es compartida, revert (lección 05-06), sin excepciones.

Queda pendiente el caso que la tabla de decisión despacha con un "ver 09-03": qué hacer cuando lo que se ha enredado no está dentro de tu repositorio, sino entre tu repositorio y el servidor. El push rechazado, el mensaje de ramas divergentes, el compañero que reescribió el historial publicado y te dejó con trabajo colgando de una base que ya no existe.

Todo eso, y el cierre de la promesa que dejamos abierta en la lección 04-05, en la lección 09-03: Resolviendo Divergencias con el Remoto.