Tema 20 · Code Review

Pull Requests (PR) y Revisión Colaborativa de Código

Aprende qué es un Pull Request (PR) en GitHub, cómo solicitar una revisión de código a tus compañeros, debatir cambios línea por línea y proteger la estabilidad de la rama principal.

Clonar Proyectos Existentes con git clone Estrategia de Ramas Profesional: Git Flow

¿Qué es un Pull Request (PR)?

Un Pull Request (PR) —también llamado Merge Request en GitLab— es una propuesta formal en la que un desarrollador le pide al equipo: «He terminado de programar esta funcionalidad en mi rama secundaria; por favor revísenla y, si está bien, incorpórenla (hagan pull) a la rama principal».

El Pull Request no es un comando de Git de consola; es una herramienta de colaboración web provista por GitHub que revolucionó la industria del software.

El Ciclo de Vida de un Pull Request Profesional

  1. Desarrollo en rama aislada: Creas tu rama (ej: feature/pasarela-bold), programas los cambios y los publicas con git push -u origin feature/pasarela-bold.
  2. Apertura del PR en GitHub: Entras a GitHub, haces clic en el botón verde «Compare & pull request», redactas una descripción clara de qué hace el cambio, qué problema resuelve y cómo probarlo.
  3. Revisión de Código (Code Review): Tus compañeros revisan el código en la pestaña Files changed, hacen comentarios constructivos, sugieren mejoras línea por línea o solicitan cambios si detectan fallos de seguridad o bugs.
  4. Chequeos Automáticos (CI/CD): GitHub Actions ejecuta automáticamente las pruebas y verificaciones de sintaxis. Si alguna prueba falla, el PR se bloquea.
  5. Fusión (Merge): Una vez aprobado por el líder técnico (Tech Lead) y con los chequeos en verde, se hace clic en «Merge pull request» y el código pasa a formar parte oficial de la rama principal.

Reglas de Protección de Ramas (Branch Protection)

En proyectos serios, GitHub permite configurar reglas para que nadie (ni siquiera el dueño del repositorio) pueda hacer un git push directo a la rama main:

  • Exigir al menos 1 o 2 aprobaciones de revisores antes del merge.
  • Exigir que todas las pruebas automatizadas pasen exitosamente.
  • Exigir que las conversaciones y comentarios hayan sido marcados como resueltos.

⚡ Flujo Completo de Creación de un Pull Request

Secuencia de pasos desde tu terminal hasta la apertura del PR en GitHub:

abrir-pull-request.sh
Solo lectura 
# 1. Asegurarse de tener la última versión de la rama base:
git switch develop
git pull

# 2. Crear una rama descriptiva para tu tarea:
git switch -c feature/filtro-recursos

# 3. Desarrollar, guardar y confirmar los cambios:
git add app/views/classroom/resources.php
git commit -m "feat(resources): agregar buscador en vivo por categoria"

# 4. Subir la rama a GitHub:
git push -u origin feature/filtro-recursos

# 5. La terminal de Git te devolverá un enlace directo para abrir el PR:
# Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
# remote: Create a pull request for 'feature/filtro-recursos' on GitHub by visiting:
# remote:      https://github.com/solucionaticos/kilopolis-core/pull/new/feature/filtro-recursos
🦉
¿Tienes dudas con este tema?
Sócrates AI puede darte analogías y explicarte este código paso a paso.

🚀 ¿Quieres dominar Manual Completo de Git & GitHub Profesional y crear proyectos reales?

Aprende arquitectura limpia, desarrollo web moderno, buenas prácticas y despliegue en producción con nuestro Bootcamp Fullstack Developer con mentorías en vivo.

Conocer el Bootcamp

🏛️ Autoría y Propiedad Intelectual: Obra educativa original de David Amador para Kilopolis Academia (Solucionáticos), estructurada sobre las especificaciones y estándares abiertos del W3C, el estándar vivo de WHATWG y la documentación oficial de código abierto. © Todos los derechos reservados.