Conecta repos remotos, sincroniza con origin/upstream y abre pull requests claras con contexto técnico.
En colaboración real, casi todo pasa por remotos y PR: subir rama, explicar el cambio, recibir feedback y mejorar antes de merge.
Una buena PR tiene contexto funcional, decisiones técnicas y checklist de pruebas. Eso reduce idas y vueltas en revisión 🔍.
Si quieres dejar preparado tu historial antes de PR, encaja muy bien repasar <a href="/curso/git-github/leccion/git-github-conflictos-rebase-ramas">conflictos y rebase</a>.
Distingue tu repo (fork) del repositorio fuente.
En proyectos colaborativos con fork, <code>origin</code> suele ser tu copia y <code>upstream</code> el repo original. Mantener ambos configurados evita desalinearte del proyecto principal.
Haz <code>fetch</code> frecuente y revisa antes de hacer push para reducir conflictos evitables.
La PR es documento técnico, no solo botón de merge.
En el cuerpo de la PR incluye: problema, solución, impacto y pruebas. Si hubo decisiones discutibles, explícalas. Eso acelera revisión y evita malentendidos.
Incluye capturas o pasos de validación cuando el cambio afecta UI o comportamiento crítico.
Conecta repos remotos, sincroniza con origin/upstream y abre pull requests claras con contexto técnico.
Código del tema: Comandos reproducibles y trazables
Distingue tu repo (fork) del repositorio fuente.
En proyectos colaborativos con fork, origin suele ser tu copia y upstream el repo original. Mantener ambos configurados evita desalinearte del proyecto principal.
Haz fetch frecuente y revisa antes de hacer push para reducir conflictos evitables.
git remote -v
git remote add upstream https://github.com/org/repo.git
git fetch upstreamLa PR es documento técnico, no solo botón de merge.
En el cuerpo de la PR incluye: problema, solución, impacto y pruebas. Si hubo decisiones discutibles, explícalas. Eso acelera revisión y evita malentendidos.
Incluye capturas o pasos de validación cuando el cambio afecta UI o comportamiento crítico.
Ayuda a aterrizar que una PR profesional documenta el problema, la solución y el feedback antes del merge.
Encaja con la parte de revisión técnica: no basta con abrir la PR, hay que inspeccionar diff, alcance y pruebas.
