131. Identidad de la lección
132. Objetivo de aprendizaje
Después de esta lección, podrás crear un checkpoint en Git, realizar un cambio desechable, recuperar el archivo rastreado hasta ese checkpoint y verificar que el estado del árbol de trabajo haya sido restaurado sin reescribir el historial de commits.
133. Por qué importa
Un checkpoint solo sirve si ofrece un punto fiable al que regresar. En un proyecto asistido por IA, los cambios pequeños pueden acumularse rápidamente, y un cambio que parece correcto todavía puede afectar un archivo que no pretendías tocar. Este ciclo de seguridad permite probar una idea sin convertir cada experimento en algo permanente. También aporta evidencia de que el repositorio está listo para el siguiente cambio deliberado.
134. Conocimientos previos
Debes haber completado Mira el cambio antes de conservarlo en este módulo. Debes poder inspeccionar git status y leer un diff antes de aceptar un cambio. También necesitas un repositorio local del proyecto con Git disponible. Si el árbol de trabajo contiene cambios que no reconoces, detente e identifícalos antes de continuar.
135. Concepto central
Un commit es un checkpoint con nombre. Para un cambio no confirmado en un archivo rastreado, git restore --source=HEAD -- ruta/al/archivo reemplaza ese archivo en el árbol de trabajo por la versión del commit actual (HEAD); no reescribe el historial de commits. La forma abreviada git restore -- ruta/al/archivo restaura el archivo desde el índice, que normalmente coincide con HEAD justo después de crear un checkpoint limpio, pero no debe describirse como una restauración inherentemente del último estado confirmado. La secuencia es importante:
- Inspeccionar el estado actual.
- Confirmar un checkpoint conocido y estable.
- Realizar un cambio desechable.
- Inspeccionar el diff.
- Restaurar únicamente el cambio desechable.
- Inspeccionar de nuevo y confirmar el estado.
git restore es apropiado aquí porque el objetivo es descartar un cambio no confirmado del árbol de trabajo. No es la misma operación que reescribir el historial con git reset o eliminar un commit de una rama compartida.
136. Modelo mental
El ritual de checkpoint
El modelo principal de esta lección es:
WORKING STATE → INSPECT → CHECKPOINT → CHANGE → INSPECT → KEEP OR REVERT
| Paso | Pregunta | Evidencia |
|---|---|---|
| WORKING STATE | ¿Qué estado existe antes de evaluar el experimento? | git status y un diff legible |
| INSPECT | ¿Qué muestra el estado actual del repositorio? | El estado y el diff relevante |
| CHECKPOINT | ¿Qué estado conocido y estable estoy protegiendo? | Un commit preciso y su identificador |
| CHANGE | ¿Qué experimento desechable único voy a realizar? | Un diff acotado en el archivo previsto |
| INSPECT | ¿La nueva evidencia coincide con el alcance intencional? | Un segundo diff y la comprobación pertinente |
| KEEP OR REVERT | ¿Debo conservar el cambio o volver al checkpoint? | Una decisión explícita respaldada por evidencia |
El bucle de interacción de Stage 1 permanece como contexto de apoyo: ACTUAR → RESPONDER → CAMBIAR → OTRA VEZ. Describe una acción, su resultado, un cambio y otro intento. No sustituye el ritual de checkpoint. Usa el ritual para proteger un estado conocido, inspeccionar el experimento y decidir si conservarlo o revertirlo.
137. Ejemplo concreto
Supón que el proyecto está en un estado conocido y estable, y quieres probar temporalmente un cambio de etiqueta en un archivo rastreado de documentación o configuración. Puedes proteger el punto de partida, editar solo ese archivo, inspeccionar el diff y después restaurarlo:
git status
git add ruta/al/archivo-rastreado
git commit -m "Checkpoint before disposable label test"
# Realiza una edición temporal y pequeña en ruta/al/archivo-rastreado.
git diff -- ruta/al/archivo-rastreado
git restore --source=HEAD -- ruta/al/archivo-rastreado
git status
git diff -- ruta/al/archivo-rastreado
Después de la restauración, la edición temporal ya no debería aparecer en el diff. El commit del checkpoint permanece en el historial. Sustituye la ruta de ejemplo por un archivo rastreado que tengas permiso para editar; no uses un archivo que contenga trabajo ajeno al ejercicio.
138. Flujo de Git
Trabaja desde la raíz del repositorio y mantén el alcance reducido.
- Ejecuta
git status --short. - Si aparecen cambios que no creaste o no puedes explicar, no los confirmes. Pide aclaraciones o vuelve primero a un estado conocido.
- Inspecciona el diff relevante con
git diffogit diff -- ruta/al/archivo. - Prepara solo los archivos conocidos y estables para este checkpoint. Evita
git add .cuando pueda existir trabajo no relacionado. - Crea el checkpoint con un mensaje preciso, por ejemplo
Checkpoint before disposable label test. - Registra el identificador corto con
git log -1 --oneline. - Realiza exactamente un cambio temporal e inocuo en un archivo rastreado.
- Ejecuta un diff limitado a esa ruta y confirma que contiene únicamente el experimento previsto.
- Restaura el archivo con
git restore -- ruta/al/archivo. - Ejecuta
git status --shorte inspecciona otra vez el diff de esa ruta.
No uses git clean, git reset --hard ni un comando de restauración amplio para este ejercicio. Pueden eliminar más cosas que el cambio temporal previsto. Si tu experimento crea un archivo no rastreado, elimínalo manualmente solo si tienes certeza de que pertenece al ejercicio, o detente e inspecciónalo en vez de asumir que git restore lo eliminará.
139. Error común
El error más común es confirmar el cambio desechable inmediatamente después de realizarlo. Eso convierte el experimento en parte del checkpoint y deja a git restore sin nada que eliminar. Otro error es interpretar un árbol limpio como prueba de que el comportamiento del juego es correcto. Un estado limpio solo demuestra que Git no detecta cambios rastreados sin confirmar; no sustituye ejecutar la comprobación correspondiente ni inspeccionar el archivo restaurado.
140. Práctica guiada
Completa esta secuencia en el repositorio del proyecto:
- ACTUAR: Ejecuta
git status --shorte inspecciona cualquier diff relevante. Anota el archivo que usarás y el estado que quieres proteger. Si el árbol no está claramente en un estado conocido y estable, detente en vez de confirmar la incertidumbre. - RESPONDER: Prepara solo los archivos conocidos y crea un commit de checkpoint. Confírmalo con
git log -1 --oneline. - CAMBIAR: En un archivo rastreado, realiza una edición pequeña, reversible y fácil de identificar. No modifiques la lógica de juego ni combines varios experimentos. Inspecciona el diff y decide si contiene exactamente el cambio que pretendías.
- OTRA VEZ: Recupera el archivo hasta el checkpoint con
git restore --source=HEAD -- ruta/al/archivo. Inspecciona el archivo, ejecutagit diff -- ruta/al/archivoy ejecutagit status --short. Esto restaura la copia del árbol de trabajo desde el checkpoint actual; no elimina ni reescribe el commit del checkpoint. - Punto de decisión: Si el estado no coincide con lo esperado, no ejecutes automáticamente un comando más fuerte. Determina si lo que queda es un archivo no rastreado, un cambio ajeno al ejercicio o una restauración con alcance incorrecto. Conserva el trabajo ajeno y corrige únicamente el cambio del ejercicio.
Repite el ejercicio una vez con otro archivo rastreado e inocuo solo si la primera pasada fue clara. El objetivo es juzgar el alcance de forma fiable, no hacerlo con rapidez.
141. Validación / evidencia
Has completado la práctica cuando puedas señalar todo lo siguiente:
- El identificador de un commit de checkpoint y un mensaje que describa el estado protegido.
- Un diff de antes y después que demuestre que el cambio temporal existía antes de restaurar y desapareció después.
- El resultado final de
git status --short, coherente con tu expectativa. - El archivo restaurado coincidiendo con el estado del checkpoint.
- Una nota escrita que explique por qué una restauración limitada a una ruta era más segura que un comando destructivo amplio.
Si el proyecto requiere una comprobación adicional de compilación o ejecución, hazla después de restaurar y registra el resultado. La evidencia de Git confirma el estado del repositorio; por sí sola no valida el comportamiento del juego.
142. Ideas clave
- Un commit es un punto de retorno deliberado, no solo un registro de actividad.
- Inspecciona el árbol de trabajo antes de confirmar y revisa el diff después de cada experimento.
- Usa
git restorelimitado a una ruta para un cambio desechable que aún no se haya confirmado. - Un comando correcto no basta; verifica el estado restaurado con
status, diff y el propio archivo. - Protege el trabajo ajeno en lugar de usar un comando amplio para que el estado parezca limpio.
143. Comprobación de conocimientos
Completa la comprobación de conocimientos de esta lección. Usa las explicaciones para comparar la elección de comandos y el estándar de evidencia con tu propia práctica.
144. Siguiente lección
Continúa con 1.ai-partner — Dirigir al socio de IA.
145. Git en Pulse Loop (fix-git-regression después)
En tu copia de Pulse Loop: git status, commit de checkpoint, un cambio desechable, inspecciona el diff, restauración acotada, verifica el estado. La evidencia es el id de commit, el diff y el archivo restaurado. El laboratorio de Etapa 3 academy-fixtures/labs/git-regression (node run.mjs) usa un repo temporal, no este repositorio del curso.
146. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
¿Cuál es el propósito de crear el checkpoint antes de realizar el cambio desechable?
Mostrar respuesta y explicación
Respuesta: Crear un punto de retorno conocido para el experimento
Por qué: El checkpoint registra el estado conocido y estable para que el experimento desechable tenga un punto deliberado de comparación y retorno.
¿Qué comando es la opción específica para descartar un cambio no confirmado en un solo archivo rastreado?
Mostrar respuesta y explicación
Respuesta: git restore -- ruta/al/archivo
Por qué: Un git restore limitado a una ruta descarta el cambio no confirmado del archivo rastreado indicado sin modificar ampliamente otros archivos ni el historial de commits.
¿Qué debes hacer si el árbol de trabajo contiene cambios que no puedes explicar antes de crear un checkpoint?
Mostrar respuesta y explicación
Respuesta: Detenerte e identificar o aclarar primero los cambios
Por qué: Un cambio que no puedes explicar puede pertenecer a trabajo no relacionado. Confirmarlo o eliminarlo sin conocer su alcance puede destruir evidencia o trabajo ajeno.
¿Qué demuestra un git status limpio después de la restauración?
Mostrar respuesta y explicación
Respuesta: Que Git no detecta cambios rastreados sin confirmar dentro del alcance inspeccionado
Por qué: Un estado limpio es evidencia sobre el estado del repositorio, no una prueba de que el juego funcione correctamente, de que el commit no tenga errores ni de que los archivos no rastreados se hayan eliminado con seguridad.