El historial forma parte del registro de producción

1338. Identidad de la lección

Módulo

3.14 — Git profesional

Lección

El historial forma parte del registro de producción

Tipo académico

Flujo de trabajo

Tipo de esquema

mixto

Orden

1

Tiempo estimado

30–45 minutos

Esta lección trata el historial de Git como evidencia de producción: un registro que ayuda a otra persona a revisar un cambio, aislar una regresión o recuperar un estado conocido.

1339. Objetivo de aprendizaje

Al terminar esta lección, podrás seleccionar una estructura de ramas y commits que haga que un cambio multipartes del juego sea revisable, recuperable y diagnosticable.

1340. Por qué importa

Un cambio multipartes puede incluir reglas de juego, presentación, datos de configuración y pruebas. Si todo queda registrado en un commit opaco, quien revisa debe reconstruir el razonamiento a partir de los archivos finales, y la recuperación se vuelve innecesariamente amplia. Los commits enfocados y las ramas con un propósito conservan las razones que dieron forma al cambio.

Esto es especialmente importante cuando la IA ayuda a producir varias modificaciones con rapidez. Esa velocidad solo es útil si el historial resultante explica qué cambió, de qué depende cada parte, cómo se comprobó y qué puede recuperarse por separado.

1341. Conocimientos previos

Ya deberías poder:

• crear, inspeccionar y cambiar de rama en Git;
• realizar commits con mensajes significativos;
• comparar cambios con git diff e inspeccionar el historial con git log;
• usar una matriz de compatibilidad para registrar combinaciones admitidas y preguntas diagnósticas, como se practicó en 3.13 L2 — Diseñar una matriz de compatibilidad.

No necesitas memorizar una estrategia universal de ramas. La meta es elegir una estructura adecuada para el cambio y sus riesgos.

1342. Concepto central

La estructura de Git debe reflejar la estructura del cambio.

Una rama establece un límite de revisión. Un commit enfocado establece un límite recuperable para una unidad coherente de razonamiento. Ambos deben elegirse según las partes del cambio, sus dependencias y el orden en que una persona revisora o investigadora futura necesite examinarlas.

Un commit enfocado no es simplemente un commit pequeño. Tiene un propósito principal y una afirmación de validación clara. El cambio de una regla y la comprobación de regresión que valida directamente esa regla pueden formar un solo commit enfocado. En cambio, un commit que cambia la regla, rediseña menús no relacionados, reformatea el proyecto y actualiza archivos de despliegue mezcla propósitos distintos aunque su mensaje sea breve.

1343. Modelo mental

La prueba del registro de producción

Para cada cambio propuesto, pregunta:

Una secuencia útil para planificar es:

Mapa del cambio → límite de la rama → orden de dependencias → commits enfocados → registro de validación

Es un modelo de decisión, no un ritual de comandos.

1344. Ejemplo concreto

Supón que un cambio añade una nueva interacción a un prototipo de juego. Tiene cuatro partes:

1. una regla de juego que determina cuándo la interacción es válida;
2. una respuesta visual que comunica el resultado;
3. datos de configuración que proporcionan el texto de la interacción;
4. una comprobación de regresión para la regla.

Un historial débil podría contener un único commit llamado add interaction. Ese historial no permite saber si un fallo posterior proviene de la regla, la presentación, los datos o la comprobación.

Un plan más sólido podría ser:

• Commit preparatorio: definir el formato de configuración compartido y añadir los datos necesarios para la interacción. Este límite es apropiado cuando el formato puede revisarse por separado y servirá para otras interacciones.
• Commit de la regla: implementar la regla de juego junto con la comprobación de regresión que la valida directamente. Ambos elementos comparten una misma afirmación de validación y no deberían separarse si la comprobación carecería de sentido sin la regla.
• Commit de presentación: añadir la respuesta visible para la persona jugadora una vez que la regla produzca un resultado estable que pueda mostrarse.

Si la presentación es necesaria para que la interacción alcance un estado válido o comprobable, debe permanecer junto con la regla. Si los datos y una comprobación respaldan realmente una misma afirmación de validación revisable por separado, pueden avanzar juntos, pero el plan debe explicar esa afirmación compartida. No deben combinarse solo porque ambos estén pendientes.

La estructura correcta depende del acoplamiento, de la validez de los estados intermedios y de la validación, no de alcanzar una cantidad fija de commits.

1345. Elegir una estructura de ramas

Antes de editar, escribe un mapa breve del cambio y elige entre estas estructuras:

• Una rama enfocada con varios commits: úsala cuando las partes formen una sola funcionalidad revisable, pero tengan límites internos útiles.
• Ramas separadas: úsalas cuando las partes tengan responsables, tiempos de entrega, riesgos o criterios de revisión distintos.
• Una rama o un commit preparatorio seguido de una rama de funcionalidad: úsalo cuando una base compartida deba revisarse antes que el comportamiento dependiente.

Las ramas separadas o apiladas solo son apropiadas cuando quedan explícitos su dependencia, la base de revisión y el orden de integración. En caso contrario, una sola rama con commits enfocados puede conservar un límite de revisión más claro y evitar ambigüedades de integración.

Para cada commit propuesto, registra:

• su propósito principal;
• los archivos o el subsistema afectados;
• los commits prerrequisito, si existen;
• la validación realizada o prevista;
• el fallo que ayudaría a aislar;
• cualquier limitación conocida o trabajo posterior.

1346. Flujo de trabajo con IA

La IA puede proponer un mapa del cambio, sugerir límites de commit o resumir un diff. No debe decidir el historial sin tu revisión.

1. Describe las partes, los riesgos y las dependencias antes de pedir un plan de Git.
2. Pide a la IA que proponga el alcance de la rama y una secuencia de commits.
3. Compara la propuesta con el acoplamiento real de los archivos y con la validación disponible.
4. Rechaza los límites que dejarían inválido un commit intermedio, ocultarían cambios no relacionados o combinarían cambios con necesidades de recuperación distintas.
5. Revisa el plan y registra por qué existe cada límite.
6. Si los commits ya existen, contrasta cualquier resumen generado por IA con git diff, git log y las comprobaciones que realmente ejecutaste.

Un prompt útil es:

Este es un cambio multipartes de un juego: [lista las partes]. Las dependencias son [lista las dependencias]. La validación disponible para cada parte es [lista las comprobaciones]. Propón el alcance de la rama y una secuencia de commits enfocados. Para cada commit, indica su propósito, prerrequisitos, validación y el fallo que ayudaría a aislar. No incluyas ni des por hecho que el formateo o la refactorización no relacionados formen parte de este cambio.

La responsabilidad de la estructura final sigue siendo tuya. Un plan generado por IA puede parecer elegante y aun así ser incorrecto si no coincide con el grafo real de dependencias del repositorio.

1347. Inspeccionar el registro resultante

Comandos como estos permiten reunir evidencia:

git status
git diff --check
git log --oneline --decorate --graph --all
git show --stat <commit>
git diff <base>...<branch>

Un estado limpio no demuestra por sí solo que el historial sea coherente. Que un comando termine correctamente tampoco demuestra que cada cambio se validara en el límite adecuado.

1348. Errores comunes

Confundir un mensaje corto con un commit enfocado

update gameplay puede describir un cambio coherente de una regla o esconder modificaciones de jugabilidad, interfaz, recursos, datos y formato. El enfoque depende del contenido, las dependencias y la afirmación de validación, no de la longitud del mensaje.

Dividir por archivo en vez de por razonamiento

Dos archivos pueden necesitar cambiar juntos para producir un estado válido. A la inversa, varias modificaciones de un mismo archivo pueden responder a propósitos y necesidades de recuperación diferentes. La cantidad de archivos no determina por sí sola el límite de un commit.

Crear ramas sin un plan de integración

Las ramas dependientes pueden ocultar qué base debe usar quien revisa y qué rama debe integrarse primero. Si esas decisiones no están claras, una sola rama con commits enfocados puede resultar más fácil de revisar y recuperar.

1349. Práctica guiada

Usa este escenario o sustitúyelo por un cambio comparable de tu propio prototipo:

Una funcionalidad añade una nueva interacción. La lógica de la regla, la respuesta visible para la persona jugadora, los datos de configuración y la comprobación de regresión están mezclados en un solo cambio de trabajo. La respuesta no puede probarse con sentido hasta que exista la regla. El formato de configuración también se necesita para otra interacción no relacionada prevista para un hito posterior.

Prepara una decisión sobre la estructura de Git:

1. Crea un mapa de cuatro filas. Para cada parte, indica su propósito, dependencia, validación y necesidad de recuperación.
2. Elige una estructura de ramas y explica su límite de revisión.
3. Si eliges ramas separadas o apiladas, indica la dependencia, la base de revisión y el orden de integración.
4. Propón una secuencia ordenada de commits. Asigna a cada commit un propósito principal y una afirmación de validación.
5. Identifica un límite que no debería dividirse porque sus partes deben avanzar juntas.
6. Identifica un límite que no debería combinarse porque sus partes tienen necesidades distintas de revisión o recuperación.
7. Explica qué commit o límite inspeccionarías primero si fallara la presentación mientras la regla siguiera pasando.
8. Pide a un asistente de IA que critique el plan. Registra una recomendación que aceptaste y otra que rechazaste, con sus razones.

Todavía no cambies los archivos del proyecto. Entrega el artefacto de planificación mediante la evaluación práctica asociada a esta lección.

1350. Validación y evidencia

1351. Ideas clave

• Una rama define un límite de revisión; un commit define un límite coherente de razonamiento y recuperación.
• Divide el trabajo cuando difieran el propósito, la validación o la recuperación; mantén juntos los cambios directamente acoplados.
• La regla y su comprobación directa de regresión suelen compartir una misma afirmación de validación.
• Las ramas dependientes requieren una base de revisión y un orden de integración explícitos.
• La IA puede proponer una estructura de Git, pero la persona desarrolladora debe contrastarla con las dependencias y comprobaciones reales.

1352. Siguiente lección

Continúa con 3.14 L2 — Revisar un conjunto de cambios asistido por IA para identificar violaciones de límites, riesgos de integración y opciones de recuperación en un conjunto de cambios asistido por IA.

1353. Comprobación