116. Objetivo de aprendizaje
Después de esta lección, podrás leer un diff de texto pequeño y explicar:
- qué archivo cambió;
- qué se eliminó y qué se añadió;
- qué condición relevante permaneció intacta; y
- si la evidencia respalda conservar, investigar o detenerse.
La mecánica de commit y restauración queda para la siguiente lección.
117. Comprobación de requisitos
Para el ejercicio de edición necesitas:
- una carpeta de proyecto que ya sea un repositorio de Git; y
- un archivo de texto pequeño, previamente rastreado, que puedas editar sin riesgo.
Ejecuta:
git status
git ls-files --error-unmatch ruta/al/archivo-de-practica.txt
Sustituye la ruta de ejemplo por la del archivo que quieras usar. Si el segundo comando muestra un error, Git no está rastreando ese archivo y no sirve para el ejercicio principal. Usa el archivo de práctica rastreado que indique tu entorno del curso u otro archivo de texto o documentación ya rastreado que puedas editar de forma inofensiva.
No uses archivos binarios, archivos generados, resultados de compilación ni archivos que controlen comportamientos importantes del proyecto. No borres ni sobrescribas trabajo previo para obtener un estado limpio; anótalo y elige otro archivo seguro si hace falta.
Un archivo nuevo sin rastrear puede aparecer en git status, pero el comando habitual git diff no muestra su contenido. Por eso el ejercicio exige un archivo previamente rastreado. Si no dispones de uno que sea seguro, completa los ejemplos de interpretación sin hacer una edición real.
118. Dos estados con funciones distintas
El checkpoint y el estado candidato no son lo mismo.
- Checkpoint: el estado de referencia conocido y funcional que se establece antes de editar. Identifica el punto desde el que se intenta el cambio.
- Estado candidato: el estado de trabajo posterior a la edición que se compara con el checkpoint.
En esta lección identificarás e inspeccionarás ambos estados sin crear un commit. La siguiente lección explica cómo un commit puede registrar un punto de restauración y cómo volver a él después de un cambio incorrecto.
119. Ritual de checkpoint
Usa el ritual canónico, con sus etiquetas estables en inglés y sus equivalentes en español:
WORKING STATE (ESTADO DE TRABAJO) → INSPECT (INSPECCIONAR) → CHECKPOINT → CHANGE (CAMBIAR) → INSPECT (INSPECCIONAR) → KEEP OR REVERT (CONSERVAR O REVERTIR)
| Paso | Pregunta |
|---|---|
| ESTADO DE TRABAJO | ¿Qué existe o funciona antes de editar? |
| INSPECCIONAR | ¿Qué muestran git status o el diff actual antes de empezar? |
| CHECKPOINT | ¿Qué estado de referencia conocido y qué condición invariable estoy protegiendo? |
| CAMBIAR | ¿Qué edición solicitada produce el estado candidato? |
| INSPECCIONAR | ¿En qué se diferencia el estado candidato del checkpoint? |
| CONSERVAR O REVERTIR | ¿La evidencia permite conservarlo o conviene investigar o detenerse? |
El bucle anterior ACT → RESPOND → CHANGE → AGAIN sigue siendo un contexto útil, pero no realiza la inspección del checkpoint. En esta lección, usa el ritual de checkpoint para tomar decisiones a partir del diff.
120. Un diff es evidencia, no un veredicto
Un diff muestra diferencias textuales entre estados. No demuestra que el comportamiento resultante sea correcto. Debes interpretarlo teniendo en cuenta:
- el cambio solicitado;
- el archivo y la región esperados;
- al menos una condición invariable que deba permanecer intacta; y
- cualquier comprobación de comportamiento disponible.
Un diff pequeño también puede ser incorrecto, y uno grande no es necesariamente incorrecto. La pregunta es si puedes explicar cada modificación relevante y si el alcance coincide con la solicitud.
121. Cómo leer un diff de texto
Supón que el checkpoint conocido contiene este archivo rastreado:
Pickup settings
heal_amount=10
max_health=100
La solicitud es: “Cambia heal_amount de 10 a 15. Mantén max_health sin cambios”. Después de editar, git diff muestra:
diff --git a/practice/pickup.txt b/practice/pickup.txt
--- a/practice/pickup.txt
+++ b/practice/pickup.txt
@@ -1,3 +1,3 @@
Pickup settings
-heal_amount=10
+heal_amount=15
max_health=100
Lee la salida mediante sus marcadores textuales, no mediante el color:
diff --git ...identifica las rutas del archivo comparado.--- a/practice/pickup.txtidentifica la versión anterior. Es una cabecera, no una línea de contenido eliminada.+++ b/practice/pickup.txtidentifica la versión nueva. Es una cabecera, no una línea de contenido añadida.@@ -1,3 +1,3 @@es la cabecera del bloque de cambios. Indica la región mostrada en ambas versiones.- Una línea de contenido que comienza por
-estaba en el checkpoint y se eliminó del estado candidato. - Una línea de contenido que comienza por
+se añadió al estado candidato. - Una línea de contenido que comienza con un espacio es contexto sin cambios. Sirve para localizar la edición y comprobar condiciones cercanas.
No dependas del resaltado rojo y verde. Los signos - y +, las cabeceras y el texto de cada línea conservan el significado aunque no haya color.
122. Interpretación modelada
Convierte el diff en una explicación sencilla mediante tres pasos.
1. Identifica el archivo afectado
El archivo modificado es practice/pickup.txt.
2. Indica qué se eliminó y qué se añadió
El estado candidato elimina heal_amount=10 y añade heal_amount=15.
Git representa esta sustitución como una línea eliminada y otra añadida.
3. Compara el alcance con la solicitud y la condición invariable
La solicitud afectaba únicamente a heal_amount. El contexto sigue mostrando max_health=100, por lo que la condición indicada permanece intacta en el diff. No aparece ningún archivo ajeno.
Decisión: conservar, siempre que la comprobación de comportamiento disponible también coincida. El diff tiene el alcance textual solicitado, pero por sí solo no demuestra el comportamiento durante la ejecución.
123. Ejemplo parcialmente resuelto
Solicitud: “Cambia el modo de práctica de focus a review. Mantén el título sin cambios”.
diff --git a/practice/session.txt b/practice/session.txt
--- a/practice/session.txt
+++ b/practice/session.txt
@@ -1,2 +1,2 @@
title=Diff practice
-mode=focus
+mode=review
Completa la interpretación:
- Archivo afectado:
practice/session.txt - Texto eliminado:
mode=focus - Texto añadido:
mode=review - Condición invariable: __________________________________
- ¿Hay una modificación ajena?: sí / no
- Decisión y motivo: __________________________________
Una respuesta completa identifica title=Diff practice como contexto sin cambios, indica que no hay modificaciones ajenas y respalda conservar porque el estado candidato coincide con el alcance solicitado.
124. Secuencia de inspección de solo lectura
Usa estos comandos para reunir evidencia:
git status
git diff
git diff --staged
git statusidentifica modificaciones rastreadas, cambios preparados y archivos sin rastrear.git diffmuestra cambios no preparados en archivos rastreados.git diff --stagedmuestra cambios preparados.
En este flujo, estos comandos se usan solo para inspeccionar. Si git status enumera un archivo sin rastrear, pero git diff no muestra nada sobre él, no concluyas que el archivo está vacío. El git diff habitual no muestra ese contenido sin rastrear.
125. Práctica guiada
Usa un archivo de texto previamente rastreado que puedas editar sin riesgo.
- Registra el estado de trabajo. Indica el archivo, el valor o línea actual y una condición cercana que deba mantenerse.
- Inspecciona antes de editar. Ejecuta
git status. Anota cualquier cambio previo sin modificarlo. - Identifica el checkpoint. Describe en una frase el estado de referencia conocido. Ejemplo: “Antes de editar,
mode=focus, el título no ha cambiado y Git rastrea el archivo”. - Define la solicitud. Describe una sustitución pequeña y lo que debe permanecer intacto.
- Haz la edición. Cambia únicamente el texto solicitado.
- Inspecciona el estado candidato. Ejecuta
git statusygit diff. Si otro flujo preparó la edición, usa tambiéngit diff --staged. - Interpreta el diff. Identifica el archivo, la línea eliminada, la línea añadida, el contexto sin cambios y cualquier modificación ajena.
- Decide. Registra conservar, investigar o detenerse. No realices todavía la restauración.
Elige investigar o detenerse si el diff contiene un archivo inesperado, una línea que no puedes explicar, una condición incumplida o una salida que todavía no sabes interpretar.
126. Interpretación práctica puntuada
La solicitud es: “Cambia heal_amount de 10 a 15. Mantén max_health en 100”.
diff --git a/practice/pickup.txt b/practice/pickup.txt
--- a/practice/pickup.txt
+++ b/practice/pickup.txt
@@ -1,3 +1,3 @@
Pickup settings
-heal_amount=10
+heal_amount=15
-max_health=100
+max_health=120
Entrega una respuesta de texto que incluya:
- el archivo afectado;
- todas las líneas de contenido eliminadas y añadidas;
- la condición invariable y si se mantuvo;
- cualquier modificación inesperada o ajena; y
- una decisión de conservar, investigar o detenerse, acompañada de una justificación de una frase.
Rúbrica: 5 puntos
- 1 punto: identifica
practice/pickup.txt. - 1 punto: identifica la eliminación y adición relativas a
heal_amount. - 1 punto: identifica la eliminación y adición relativas a
max_health. - 1 punto: indica que se incumplió la condición
max_health=100. - 1 punto: elige investigar o detenerse y relaciona la decisión con el cambio inesperado de salud máxima.
No hace falta entregar una imagen. Se acepta el diff copiado como texto junto con una interpretación escrita.
127. Registro de validación
Para tu edición real, entrega:
- el checkpoint conocido anterior a la edición;
- el cambio solicitado y una condición invariable;
- la observación relevante de
git status; - el diff resultante copiado como texto;
- el archivo afectado;
- las líneas eliminadas y añadidas;
- el contexto sin cambios usado como evidencia;
- cualquier modificación inesperada, o una afirmación explícita de que no apareció ninguna; y
- una decisión de conservar, investigar o detenerse justificada mediante la evidencia.
Has alcanzado el objetivo cuando otra persona desarrolladora puede leer el registro, distinguir el checkpoint del estado candidato, reconstruir el pequeño cambio textual y entender por qué la decisión se desprende del diff.
128. Ideas clave
- El checkpoint es el estado de referencia conocido anterior al cambio; el estado candidato es el resultado posterior a la edición que se está inspeccionando.
-marca contenido eliminado,+marca contenido añadido y las líneas precedidas por un espacio aportan contexto sin cambios.- Las cabeceras del archivo y del bloque localizan la comparación, pero no son ediciones de contenido.
- Los archivos sin rastrear pueden aparecer en
git statussin aparecer en elgit diffhabitual. - Para decidir conservar, el diff debe coincidir con la solicitud y respetar la condición invariable indicada.
129. Siguiente lección
Continúa con 1.checkpoints L2 — Checkpoint, cambiar y revertir, donde aprenderás a registrar un punto de restauración y volver a él después de un cambio incorrecto.
130. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
¿Cuál es la función principal de un diff dentro del ritual de checkpoint?
Mostrar respuesta y explicación
Respuesta: Aportar evidencia que debe interpretarse según la solicitud y las condiciones que debían mantenerse
Por qué: Un diff muestra modificaciones textuales. Debes compararlas con el alcance solicitado, las condiciones que debían mantenerse y las comprobaciones de comportamiento disponibles.
¿Qué afirmación distingue correctamente el checkpoint del estado candidato?
Mostrar respuesta y explicación
Respuesta: El checkpoint es el estado de referencia conocido anterior al cambio; el estado candidato es el resultado posterior a la edición que se está inspeccionando.
Por qué: El checkpoint establece el estado de referencia conocido antes de editar. La edición produce el estado candidato, que se compara con esa referencia.
Un archivo de texto nuevo y sin rastrear aparece en git status, pero el git diff habitual no muestra su contenido. ¿Cuál es la interpretación correcta?
Mostrar respuesta y explicación
Respuesta: El git diff habitual no muestra el contenido de un archivo sin rastrear, por lo que el ejercicio principal debe usar un archivo de texto previamente rastreado.
Por qué: git status puede informar de un archivo sin rastrear aunque el git diff habitual no muestre su contenido.
En un diff de texto, ¿qué significan los marcadores de las líneas de contenido?
Mostrar respuesta y explicación
Respuesta: - marca contenido eliminado, + marca contenido añadido y un espacio inicial señala contexto sin cambios.
Por qué: Los marcadores textuales permiten leer el diff sin depender del color. Las cabeceras como --- a/archivo y +++ b/archivo identifican versiones y no son ediciones normales de contenido.
**Solicitud: “Cambia heal_amount de 10 a 15 y mantén max_health en 100”. Lee este diff y selecciona todas las observaciones correctas:
diff --git a/practice/pickup.txt b/practice/pickup.txt
--- a/practice/pickup.txt
+++ b/practice/pickup.txt
@@ -1,3 +1,3 @@
Pickup settings
-heal_amount=10
+heal_amount=15
-max_health=100
+max_health=120
```**
A. El archivo afectado es `practice/pickup.txt`.
B. El estado candidato sustituye `heal_amount=10` por `heal_amount=15`.
C. Se incumplió la condición `max_health=100` porque el estado candidato añade `max_health=120`.
D. Solo cambió el valor de curación solicitado.
<details>
<summary>Mostrar respuesta y explicación</summary>
*Respuesta:* El archivo afectado es `practice/pickup.txt`.; El estado candidato sustituye `heal_amount=10` por `heal_amount=15`.; Se incumplió la condición `max_health=100` porque el estado candidato añade `max_health=120`.
*Por qué:* El diff afecta a `practice/pickup.txt` y modifica ambos valores. El cambio de curación coincide con la solicitud, pero el cambio de salud máxima incumple la condición indicada.
</details>