Git, revisión e historial de cambios
Convierte tus cambios en una secuencia que otra persona pueda entender y revisar con seguridad.
AL TERMINAR, PODRÁS
- Distinguir el directorio de trabajo, el área de preparación y el commit
- Crear un cambio coherente con una explicación útil
- Revisar comportamiento y riesgo, no solo estilo
Descripción del diagrama: main → 1 (rama); 1 → 2; 2 → Revisión (pull request); Revisión → integrado (aprobado); main → integrado (main sigue avanzando)
Un commit es una instantánea elegida
Git guarda instantáneas conectadas por un historial.
Tu directorio de trabajo (working tree) contiene los archivos actuales; el área de preparación (staging area) selecciona lo que tendrá el siguiente commit (registro de cambios). Un commit guarda ese estado seleccionado con metadatos y una relación con su commit padre. Antes de hacer commit, revisa tanto el diff (las diferencias) completo como el diff preparado.
Los archivos no rastreados no se incluyen automáticamente. Deja fuera del historial los archivos generados y los secretos cuando no correspondan. Una rama (branch) es una referencia móvil a un commit, no una copia completamente separada de cada archivo.
Que el cambio cuente una sola historia
Un cambio útil responde tres preguntas: qué problema ocurría, qué comportamiento cambia y cómo se comprobó.
Un commit pequeño y coherente es más fácil de revisar y de revertir que una mezcla de limpieza sin relación con trabajo nuevo. Quien revisa necesita las suposiciones y los casos límite que no son evidentes en el código. En Relay, explica por qué cambia un límite de reintentos, cómo afecta a los trabajos existentes y qué pruebas (tests) cubren el límite.
Menciona directamente las limitaciones importantes en lugar de presentar el éxito de las pruebas como confianza ilimitada.
Usa el desacuerdo como información
La revisión de código (code review) comprueba corrección, mantenibilidad, compatibilidad y consecuencias operativas.
Pregunta si las entradas pueden violar una suposición, si una falla es visible y si los cambios de estado pueden dejar datos inconsistentes. Distingue las correcciones obligatorias de las preferencias para que el autor sepa qué bloquea el avance. Un conflicto de merge es un solapamiento de texto; resolverlo no demuestra que el comportamiento combinado sea correcto.
Lee la intención que lo rodea y ejecuta las comprobaciones relevantes después de resolverlo. Cuando la colaboración es difícil, un ejemplo diminuto que se pueda ejecutar suele resolver la ambigüedad más rápido que un debate abstracto.
ERROR FRECUENTE
Un merge sin conflictos puede combinar suposiciones incompatibles. Git entiende texto e historial, no la semántica que quieres para tu programa.
INTÉNTALO TÚ
Escribe la descripción de revisión para cambiar el límite de reintentos de Relay. Incluye el problema, el comportamiento esperado, las implicaciones de compatibilidad y una prueba de caso límite.
Decide en el laboratorio.
El checkpoint de dos preguntas, tus notas y tu progreso guardado están en el laboratorio. Gratis y sin cuenta.
Abrir en el laboratorio ↗CONÉCTALO CON RELAY
Crea un cambio revisable en Relay con un solo propósito claro, una justificación breve y el comando de verificación registrado.