Pull Request: qué es, proceso de creación y code review

¿Qué es un Pull Request?

Pull Request (PR) es una solicitud formal para incluir cambios de una rama a otra dentro de un sistema de control de versiones distribuido. El PR es un elemento central del desarrollo colaborativo en las plataformas GitHub, GitLab y Bitbucket, combinando discusión de código, pruebas automatizadas y el proceso de aprobación de cambios.

El nombre “Pull Request” refleja la esencia de la operación: un desarrollador pide (request) al propietario del repositorio que “extraiga” (pull) sus cambios. El término fue introducido por GitHub en 2008 — antes de eso, existía un mecanismo similar en forma de parches y merge requests (término de GitLab). Hoy en día, el PR es el estándar de facto para el desarrollo en equipo con Git.

Según GitHub Octoverse, 2025, el 89% de los proyectos open-source requieren la creación de un PR para realizar cambios. En el desarrollo corporativo, esta cifra alcanza el 95%. El PR se ha convertido no solo en una herramienta técnica, sino en parte de la cultura de desarrollo: a través de los PR se produce la transferencia de conocimiento, la detección de errores y la alineación de decisiones arquitectónicas.

Componentes de un Pull Request

Un PR típico consta de un título, descripción, lista de archivos modificados (diff), comentarios de los revisores y estados de las verificaciones CI. Cada PR está vinculado a una rama de origen y una rama objetivo específicas, y después de fusionarse puede eliminarse automáticamente.

Cómo crear un Pull Request

Crear un PR comienza con la publicación de una rama de funcionalidad en el repositorio remoto. Después del push, el desarrollador abre un PR a través de la interfaz de la plataforma o mediante CLI (gh, glab). Veamos el proceso con GitHub como ejemplo.

Push de la rama y apertura del PR

El primer paso es hacer push de la rama de funcionalidad al repositorio remoto y crear un Pull Request a través de la interfaz web o la línea de comandos.

# Crear y subir una rama de funcionalidad
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# Crear un PR mediante GitHub CLI
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

Después de crear un PR, GitHub ejecuta automáticamente los pipelines de CI (GitHub Actions), verifica conflictos con la rama objetivo e invita a los revisores. La plantilla de descripción del PR se puede configurar mediante .github/PULL_REQUEST_TEMPLATE.md para que todos los PR contengan las secciones requeridas: objetivo, cambios, pruebas, tareas relacionadas.

Descripción y etiquetado

Una descripción de PR de calidad incluye: un enlace a la tarea (issue/ticket), una breve descripción de los cambios, instrucciones de prueba y una lista de cambios relacionados. Las etiquetas (bug, feature, refactoring) ayudan a categorizar el PR, mientras que los assignees y reviewers se asignan automáticamente mediante CODEOWNERS.

# Asignar revisores mediante CODEOWNERS (archivo en la raíz del repositorio)
# Ejemplo .github/CODEOWNERS:
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# Crear un PR asignando revisores mediante gh cli
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS es un mecanismo estándar de GitHub/GitLab para asignar revisores automáticamente según los archivos modificados. Por ejemplo, cualquier cambio en el directorio src/auth/ asigna automáticamente a team-auth y senior-dev como revisores. Esto acelera el proceso y garantiza que las personas adecuadas vean el PR.

Actualización del PR según las revisiones

Después de recibir los comentarios del revisor, el desarrollador realiza correcciones en la misma rama de funcionalidad y hace push de nuevos commits — el PR se actualiza automáticamente. Es importante no reescribir el historial (rebase) en una rama de funcionalidad publicada si el PR ya está abierto, ya que esto rompe los enlaces a commits específicos en los comentarios.

# Realizar cambios según los comentarios del revisor
git checkout feature/biometric-auth
# corregir el código
git commit -m "fix: handle biometric timeout per review"
git push

# el PR se actualizará automáticamente
# Después de la aprobación — fusionar el PR mediante la interfaz de GitHub

El proceso de code review

El code review es un elemento central de un Pull Request. El revisor verifica los cambios en cuanto a corrección, estilo de código, seguridad y coherencia arquitectónica. Una revisión de calidad no solo previene errores, sino que también difunde el conocimiento sobre la base de código dentro del equipo.

Las Engineering Practices de Google (2025) recomiendan los siguientes principios de code review: el revisor debe entender el contexto de los cambios, dar recomendaciones específicas en lugar de comentarios generales, y separar los comentarios técnicos y estilísticos. El tiempo de revisión no debe exceder las 24 horas desde el momento de creación del PR.

Para el desarrollo móvil, el code review incluye verificaciones específicas: compatibilidad con targetSdk, manejo correcto del lifecycle (Android) / view lifecycle (iOS), ausencia de fugas de memoria (LeakCanary, Instruments), soporte de tema oscuro y localización. Estas verificaciones se pueden automatizar mediante linters y Detekt/ktlint.

Tipos de comentarios

Las plataformas de PR admiten tres tipos de comentarios: generales (a todo el PR), en línea (a una línea específica de código) y sugerencias (con código de reemplazo). Las sugerencias permiten aplicar cambios con un solo clic, acelerando el proceso y reduciendo el número de iteraciones.

Después de que todos los comentarios están resueltos y las verificaciones CI pasan, el revisor envía una aprobación (Approved). El PR se puede fusionar. GitHub y GitLab admiten reglas de protección de ramas: número requerido de aprobaciones, verificaciones CI obligatorias y prohibición de hacer push a main sin PR. Para proyectos móviles, la protección de ramas también incluye verificación de compilación: un PR no se puede fusionar si la aplicación no compila (gradle build failed / xcodebuild failed).

Resolución de conflictos en PR

Los conflictos de fusión en un Pull Request son una situación común en el trabajo en equipo activo. Las plataformas ofrecen resolución de conflictos a través de la interfaz web (para conflictos simples) o recomiendan resolverlos localmente. GitHub Actions verifica automáticamente la capacidad de fusión con cada push a la rama de funcionalidad y marca el PR como conflictivo si la fusión no es posible.

Mejores prácticas de Pull Request

Los Pull Requests efectivos aceleran el code review y reducen la cantidad de errores. Un estudio de SmartBear (2025) mostró que los PR de hasta 200 líneas de código reciben 2 veces más comentarios significativos que los PR de más de 1000 líneas, y el tiempo de revisión se reduce 3 veces.

• PR pequeños — el tamaño óptimo es de 100 a 300 líneas. Divida los PR grandes en partes lógicas: cada PR resuelve una tarea. Esto simplifica la revisión y reduce la probabilidad de conflictos
• Descripción clara — título según Conventional Commits (feat:, fix:, refactor:), el cuerpo contiene “qué y por qué” en lugar de “cómo” (el código habla por sí mismo). Plantilla: objetivo → cambios → pruebas → issues relacionados
• Retroalimentación rápida — revisión dentro de 24 horas. Si un PR espera más de un día, el equipo pierde contexto y aumenta la cantidad de conflictos de fusión
• Automatización — los linters, formateadores y pruebas deben ejecutarse automáticamente al crear un PR. No permita fusionar PR con verificaciones CI en rojo
• Draft PR — úselo para discusión temprana de arquitectura. El Draft PR no requiere revisión y no se puede fusionar, pero permite mostrar el código a los colegas en una etapa temprana

Prácticas adicionales: no cree PR el viernes por la noche (nadie lo revisará hasta el lunes), solicite revisión de 1 a 2 personas (más ralentiza el proceso sin mejorar la calidad), use squash merge para comprimir el historial antes de fusionar. Para proyectos móviles, también se recomienda agregar un enlace al build de prueba (Firebase App Distribution / TestFlight) en la descripción del PR para que el revisor pueda verificar los cambios en la aplicación en funcionamiento.

Pull Request en diferentes plataformas

Las principales plataformas para trabajar con Pull Requests son GitHub, GitLab y Bitbucket. A pesar del concepto compartido, cada una tiene características que vale la pena considerar al elegir una herramienta para el equipo.

GitHub es la plataforma más popular con la comunidad más grande, Actions para CI/CD y un ecosistema extenso de aplicaciones (GitHub Marketplace). GitLab se destaca por su CI/CD integrado y la capacidad de implementación completa self-hosted. Bitbucket está estrechamente integrado con Jira y el ecosistema de Atlassian, popular en entornos corporativos.

Para el desarrollo móvil, la elección de la plataforma a menudo está determinada por las capacidades de CI/CD: GitHub Actions admite runners de macOS para compilaciones de iOS, GitLab tiene runners integrados para iOS/Android, Bitbucket se integra bien con Firebase Test Lab. Independientemente de la plataforma, el proceso de PR sigue siendo el mismo: rama → revisión → CI → fusión.