Vuelve una hora atrás

Qué es y por qué importa

Nos pasa a todos. Le pides a Claude un cambio, hace diez, y una hora después la app ya no arranca. No sabes qué ha tocado y no te acuerdas de cómo estaba antes.

Git es la historia del proyecto. Cada vez que guardas con un commit haces una foto de todos los archivos en ese momento. Si algo se rompe, vuelves a una foto anterior. Pero solo vuelves a una foto que existe: si no has guardado, no hay un antes al que volver.

Los comandos de Git no tienes que aprenderlos. Los escribe Claude. A ti te bastan tres frases, tal cual, en los tres momentos adecuados: antes de empezar, cuando algo se rompe, antes de algo grande.

Solo hace falta que el proyecto use Git. Si todavía no lo usa, pídele a Claude que lo configure: es una línea.

1. Antes de empezar: guarda

Antes de darle un trabajo a Claude, escribo esto:

Antes de tocar nada, guarda el estado actual del proyecto con un commit, así podemos volver aquí.

Claude hace un commit: guarda el estado actual con un mensaje que dice qué hay dentro. Ese commit se convierte en el punto seguro. Pase lo que pase después, puedes volver ahí.

Lo hago también a mitad del trabajo, cuando una parte funciona. Cuantas más fotos haces, más cerca está el punto al que puedes volver. Si el último commit es de ayer, volver atrás significa perder todo lo que has hecho hoy.

2. Cuando algo se rompe: vuelve atrás

Cuando la app deja de funcionar y no entiendo por qué, no le pido a Claude que arregle el arreglo del arreglo. Escribo:

Vuelve a como estaba hace una hora. Antes guarda lo que todavía no está guardado y no borres nada del historial: quiero poder cambiar de idea.

La frase tiene tres partes, y cada una cuenta.

• «Vuelve a como estaba hace una hora»: Claude mira el historial del proyecto y busca el último commit antes de ese momento. También puedes decir «a anoche» o «a antes de que tocaras el login».
• «Antes guarda lo que todavía no está guardado»: los cambios que no están en un commit son los más frágiles. Claude los pone a salvo antes de moverse, con un commit o con git stash, que los aparta para recuperarlos después.
• «No borres nada del historial»: así Claude usa git revert, que no borra los commits equivocados sino que añade uno nuevo que los deshace. Todo el historial sigue ahí: si te das cuenta de que una parte del trabajo de la última hora estaba bien, la recuperas.

Lo contrario es git reset --hard. Lleva el proyecto atrás y tira los cambios no guardados de los archivos, sin pasar por la papelera. A veces hace falta, pero es el comando con el que se pierde trabajo. Por eso en mi frase está «quiero poder cambiar de idea».

Cuando ha terminado, le pido una confirmación:

Dime a qué commit has vuelto, qué has deshecho y pasa los tests para ver si ahora funciona.

3. Antes de algo grande: una rama nueva

Rehacer el login, cambiar la base de datos, reescribir una página entera: son trabajos en los que las cosas pueden torcerse a mitad. Antes de empezar escribo:

Haz este trabajo en una rama nueva. Si funciona y los tests pasan, únela a la principal. Si no funciona, tira la rama y vuelve a la buena.

Una rama es una versión paralela del proyecto. Claude trabaja en ella, hace sus commits, y la versión principal, normalmente main, se queda como estaba. Si el trabajo funciona, la une: es el merge, los cambios de la rama entran en la versión principal. Si no funciona, tira la rama y vuelves a estar en el punto bueno.

«Los tests pasan» es la parte que cuenta. Sin una comprobación, «funciona» solo quiere decir que a Claude le parece terminado. Si el proyecto no tiene tests, pídele al menos que arranque la app y que te diga cómo lo ha comprobado.

Una rama cambia los archivos en la misma carpeta del proyecto, así que un trabajo cada vez. Si quieres varias sesiones de Claude en paralelo, cada una en su rama, necesitas los worktrees: una carpeta separada para cada rama. Hablo de ellos en la guía ALBERI (strikt.fit/alberi).

4. Además: los checkpoints de Claude Code

Además de Git hay una red más pequeña, ya dentro de Claude Code. Cada vez que mandas un mensaje, Claude Code se apunta el estado de los archivos que Claude modifica con sus propias herramientas. Estos puntos se llaman checkpoints, y los hace solo.

Para volver a uno de estos puntos pulsa Esc dos veces con el campo vacío, o escribe /rewind. Si en el campo hay texto, el doble Esc solo lo borra. Se abre la lista de los mensajes que has mandado: eliges el punto y qué restaurar.

• El código y la conversación: vuelves a ese punto con los dos.
• Solo la conversación: el chat vuelve a ese mensaje, los archivos se quedan como están ahora.
• Solo el código: los archivos vuelven a como estaban, la conversación se queda.

Las dos opciones sobre el código solo aparecen si después de ese punto Claude ha modificado archivos.

Lo que no deshacen

• Los comandos de terminal. Si Claude borra o mueve un archivo con rm o mv, el rewind no lo trae de vuelta.
• Los cambios hechos fuera de Claude Code: los archivos que cambias tú a mano en el editor, o que cambia otra sesión, normalmente no se registran.

Cuánto duran

Los checkpoints se guardan con la conversación. Si cierras el terminal y luego retomas la misma sesión, todavía puedes hacer rewind. Pero siguen ligados a esa sesión: una sesión nueva empieza sin ellos. Y por defecto Claude Code borra las copias de los archivos unos 30 días después, junto con los datos viejos de la sesión.

Por eso no sustituyen a Git. Son el botón de deshacer de la sesión. La historia de verdad del proyecto la guarda Git.

5. Una regla de seguridad

El trabajo que todavía no está guardado es el que puedes perder de verdad, y la forma más común es un reset. Por eso cada frase le dice a Claude que guarde antes. Puedes añadir:

No uses nunca git reset --hard sin preguntármelo.

Si quieres que valga siempre, ponla en el CLAUDE.md del proyecto, el archivo que Claude lee al principio de cada sesión. Sigue siendo una instrucción: Claude la sigue, pero no es un bloqueo. Para un bloqueo de verdad está la lista deny en la configuración, que para el comando antes de que se ejecute: la explico en la guía JEV (strikt.fit/jev).

Errores comunes

• Trabajar horas sin un commit: Git solo vuelve a los guardados que existen, así que haz que guarde antes de cada trabajo y cuando una parte funciona.
• Hacer arreglar el arreglo sin fin: después de dos intentos fallidos vuelve al punto bueno y empieza de nuevo con una petición más clara.
• Contar con el rewind para todo: no deshace los comandos de terminal ni los cambios hechos fuera de Claude Code, así que la red de verdad sigue siendo Git.
• Dejar pasar un git reset --hard: tira el trabajo no guardado, así que pide git revert y que guarde antes.
• Hacer algo grande sobre la versión principal: empiézalo en una rama nueva, así si sale mal tiras la rama y no pierdes nada.
• Unir una rama sin comprobar: pasa los tests antes del merge, no después.

Lista de comprobación

• El proyecto usa Git
• Commit antes de cada trabajo
• Commit cuando una parte funciona
• Para volver atrás: git revert, nada de reset
• Las cosas grandes en una rama nueva
• Tests antes de unir la rama
• Rewind solo para los cambios de Claude en la sesión

Preguntas frecuentes