Un agente de IA puede rehacer medio proyecto en una tarde. También puede borrar una hoja de estilos, sobrescribir un archivo de configuración o dejar una carpeta en un estado que nadie recuerda. Si la única copia está en un portátil, un disco averiado o un prompt equivocado pueden costarte días de trabajo. La pregunta práctica es sencilla: ¿qué recupera de verdad tu proyecto?
Git y GitHub: dos funciones distintas
Git es un sistema de control de versiones: un programa que guarda instantáneas de tu proyecto, llamadas commits. Cada commit es un estado guardado al que puedes volver más tarde. GitHub es un servicio que aloja repositorios Git. Un repositorio es la carpeta del proyecto junto con todo su historial. Al subir (push) tus commits a GitHub, queda una segunda copia de ese historial en un servidor fuera de tu equipo.
Aquí importa la visibilidad. Según la documentación de GitHub, los repositorios privados solo son accesibles para ti, para las personas a las que das acceso de forma explícita y, en las organizaciones, para ciertos miembros. Los repositorios públicos son accesibles para cualquiera en internet. Los administradores pueden cambiar la visibilidad después. Para un proyecto personal o un agente interno, lo sensato es empezar en privado.
Qué pueden deshacer los checkpoints y /rewind de Claude Code
Claude Code tiene su propia red de seguridad. Antes de cada prompt que inicia un turno, guarda el estado de los archivos que Claude edita con sus herramientas de edición. El menú de rebobinado se abre con /rewind o pulsando Esc dos veces con la entrada vacía. Desde ahí puedes restaurar el código y la conversación, solo la conversación o solo el código. Los checkpoints se guardan con la conversación, así que siguen disponibles al reanudar una sesión.
Los límites están igual de claros en la documentación. Un archivo modificado solo con comandos de Bash no se rastrea. Los cambios manuales hechos fuera de Claude Code y los de otras sesiones simultáneas normalmente no se capturan. Las ediciones de la mayoría de los subagentes no se restauran. Claude Code conserva instantáneas de archivos para los 100 checkpoints más recientes de una sesión y, por defecto, las borra unos 30 días después de la última que guardó.
Por qué hacer commit de todos modos
La documentación lo responde sin rodeos: los checkpoints sirven para recuperarse rápido dentro de una sesión, y recomienda seguir usando un control de versiones como Git para commits, ramas e historial a largo plazo. Rewind es un botón de deshacer para una sesión de trabajo. Un commit subido a GitHub existe con independencia de esa sesión y de tu portátil.
Por eso no compiten. Usa rewind cuando los últimos prompts salieron mal. Trae la versión de GitHub cuando el daño es mayor, cuando cambias de ordenador o cuando la propia carpeta ha desaparecido. Un hábito útil: haz commit en cada punto estable y pide al agente que lo haga tras cada cambio importante o al final del día.
Cómo mantener las claves de API fuera del repositorio
Muchos proyectos guardan secretos, como claves de API o credenciales de bases de datos, en un archivo .env. Ese archivo no debe acabar en el repositorio. La herramienta habitual es .gitignore, un archivo con las rutas que Git debe ignorar. El manual de Git es preciso con su alcance: indica archivos sin seguimiento que se ignoran a propósito, y no afecta a los archivos que Git ya sigue.
Un detalle pequeño, una gran diferencia. Si un .env se incluyó una vez en un commit, añadirlo después a .gitignore no lo saca del seguimiento. Según el manual, primero hay que quitarlo del índice con git rm --cached y luego añadirlo a .gitignore. Como los archivos ignorados nunca se suben, guarda una copia aparte y segura de tus secretos.
Valoración del editor
El hecho: los checkpoints y Git cubren plazos distintos, y la propia documentación de Claude Code dice que rewind no sustituye al control de versiones. Mi conclusión: el momento delicado no es el primer commit, sino el primer push. Antes, comprueba la visibilidad del repositorio y que .env de verdad no tenga seguimiento, no solo que figure en .gitignore. Un agente puede hacer estos pasos por ti, pero el resultado te toca revisarlo a ti.
