Conviene haber comprendido Remotos, autenticación y sincronización.
Avanza en orden. Cada lección está redactada para Palta es Cool, utiliza ejemplos propios y termina con una actividad cuya respuesta puedes desplegar.
Ubícate antes de avanzar
Al terminar deberías poder relacionar Flujo colaborativo con Revisión y pull request y resolver un caso nuevo.
Reserva entre 75 y 120 minutos o divide el laboratorio en dos sesiones.
Instala Git y utiliza Git Bash, PowerShell o una terminal Unix. Mantén un repositorio desechable para probar recuperación y conflictos.
Abrir la guía de herramientas →Diagnóstico rápido: ¿cómo se relacionan Flujo colaborativo y Revisión y pull request? +
No necesitas acertar todavía. Escribe una hipótesis de dos líneas y compárala con tu respuesta al finalizar; si puedes corregirla y justificar el cambio, hubo aprendizaje.
Aprende el tema paso a paso
Diseñarás un flujo colaborativo que permita comprender, revisar y verificar cada cambio antes de integrarlo.
- Ramas breves y cambios enfocados facilitan integrar
- Un pull request explica problema, solución, evidencia y límites
- Hooks y CI ayudan, pero no sustituyen criterio
Ramas breves y cambios enfocados facilitan integrar
Una rama representa un objetivo, no una persona ni una carpeta permanente. Actualizarla con frecuencia, limitar su tamaño y separar decisiones reduce conflictos y hace que la revisión llegue cuando todavía se puede cambiar el diseño.
Describe resultado y alcance antes de comenzar.
Publica una rama para respaldo y colaboración, no como sustituto de commits locales.
Elimina la rama después de integrar y verificar.
¿Por qué una rama con semanas de cambios mezclados es difícil de revisar?
Mostrar respuesta +
Porque aumenta divergencia, conflictos y carga mental; además resulta difícil distinguir decisiones, riesgos y pruebas.
Un pull request explica problema, solución, evidencia y límites
La revisión no consiste solo en aprobar código. La descripción permite reproducir el problema, comprender la decisión y comprobarla. El diff debe ser lo bastante pequeño para leerlo; los comentarios se resuelven con conversación y cambios trazables.
Relaciona el cambio con una necesidad concreta.
Incluye cómo probar y qué resultado esperar.
Declara lo que queda fuera para evitar supuestos.
¿Una captura de pantalla reemplaza las instrucciones de prueba?
Mostrar respuesta +
No. Puede aportar evidencia visual, pero otra persona necesita pasos, condiciones y resultado esperado para verificar.
Hooks y CI ayudan, pero no sustituyen criterio
Un hook local puede ejecutar formato o pruebas antes de confirmar, pero no se comparte automáticamente como comportamiento activo. La integración continua ejecuta comprobaciones en un entorno conocido al publicar cambios. Ambas deben ser rápidas, comprensibles y reparables.
Documenta cómo ejecutar la misma prueba localmente.
No escondas cambios automáticos inesperados.
Protege main exigiendo revisiones y comprobaciones proporcionales al riesgo.
¿Por qué una prueba verde no demuestra por sí sola que el cambio es correcto?
Mostrar respuesta +
Porque las pruebas cubren escenarios definidos y pueden omitir requisitos, seguridad, usabilidad o integración. La revisión complementa la automatización.
Tu recorrido en tres ideas
- Ramas breves y cambios enfocados facilitan integrar
- Un pull request explica problema, solución, evidencia y límites
- Hooks y CI ayudan, pero no sustituyen criterio
Comprueba que puedes usarlo
Antes de continuar, revisa estos tropiezos frecuentes y resuelve un caso sin copiar los ejemplos.
Enviar una revisión enorme sin instrucciones para probar.
Tratar una automatización verde como reemplazo de la revisión humana.
Ahora hazlo sin guía
Prepara la descripción de un pull request con problema, alcance, prueba, evidencia y límites.
Mostrar pauta de corrección +
- Otra persona puede reproducir la comprobación.
- El cambio responde a un objetivo.
- Las automatizaciones tienen una forma equivalente de ejecución local.
