¿Qué es un Pull Request (PR)?

Un Pull Request (PR), también conocido como Merge Request (MR) en GitLab, es una solicitud formal para integrar cambios de código desde una rama (branch) a otra dentro de un repositorio de control de versiones. Es el mecanismo central de colaboración en equipos de desarrollo modernos, donde los cambios pasan por un proceso de revisión antes de fusionarse al código principal.

Según el informe State of the Octoverse de GitHub (2023), la plataforma albergaba más de 330 millones de Pull Requests activos en 2023, con un crecimiento del 25% interanual. El estudio también reveló que los proyectos que implementan revisiones de código obligatorias tienen un 15% menos de defectos en producción (GitHub Octoverse Report, 2023).

Como explica Martin Fowler, ingeniero jefe de ThoughtWorks y autor de Refactoring (Addison-Wesley): "La revisión de código a través de Pull Requests no es solo una práctica de calidad; es el mecanismo más efectivo para compartir conocimiento dentro de un equipo."

1. Crear una rama (branch)

El desarrollador crea una nueva rama a partir de la rama principal (generalmente main o develop):

git checkout -b feature/nueva-funcionalidad

Las convenciones de naming más comunes para ramas son:

Prefijo	Uso	Ejemplo
feature/	Nueva funcionalidad	feature/login-con-google
fix/ o bugfix/	Corrección de bug	fix/error-validacion-email
hotfix/	Corrección urgente en producción	hotfix/crash-pago-tarjeta
chore/	Tareas de mantenimiento	chore/actualizar-dependencias
refactor/	Refactorización de código	refactor/servicio-pagos
docs/	Cambios en documentación	docs/api-endpoints

2. Hacer commits

El desarrollador realiza cambios y los registra con commits atómicos y descriptivos:

git add src/auth/google-login.ts git commit -m "feat: add Google OAuth2 login flow" git add src/auth/google-login.test.ts git commit -m "test: add unit tests for Google login"

La convención de Conventional Commits (conventionalcommits.org) estandariza los mensajes de commit con prefijos como feat:, fix:, docs:, test:, refactor:, chore:.

3. Crear el Pull Request

Una vez los cambios están listos, se crea el PR en la plataforma (GitHub, GitLab, Bitbucket):

# Usando GitHub CLI gh pr create --title "feat: Login con Google OAuth2" \ --body "## Descripción Implementa el flujo de autenticación con Google OAuth2. ## Cambios - Nuevo endpoint /auth/google - Integración con Google Identity Services - Tests unitarios y de integración ## Testing - [x] Tests unitarios - [x] Tests de integración - [ ] Test manual en staging"

4. Revisión de código (Code Review)

Los revisores examinan los cambios, dejan comentarios y solicitan modificaciones si es necesario. Según una investigación de SmartBear Software (Best Practices for Code Review, 2023), las revisiones más efectivas:

• Revisan menos de 400 líneas de código a la vez (la efectividad cae drásticamente con PRs más grandes)
• Dedican no más de 60 minutos por sesión de revisión
• Se centran tanto en la lógica de negocio como en la calidad del código

5. Aprobación y merge

Una vez aprobado, el PR se fusiona a la rama destino. Las estrategias de merge más comunes son:

Estrategia	Comando	Cuándo usar
Merge commit	git merge --no-ff	Preservar el historial completo de la rama
Squash and merge	git merge --squash	Agrupar todos los commits en uno solo
Rebase and merge	git rebase	Historial limpio y lineal

Título claro y conciso

El título debe describir qué se hace, no cómo:

• Bien: "Agregar autenticación con Google OAuth2"
• Mal: "Cambios en auth.ts y login.tsx"
• Bien: "Corregir cálculo de IVA en facturas internacionales"
• Mal: "Fix bug"

Descripción completa

Una buena descripción de PR responde a estas preguntas:

1. ¿Qué? — Qué cambios introduce este PR
2. ¿Por qué? — Qué problema resuelve o qué valor aporta
3. ¿Cómo? — Decisiones de diseño relevantes o enfoque técnico elegido
4. ¿Cómo probarlo? — Instrucciones para verificar los cambios
5. ¿Qué queda pendiente? — Limitaciones conocidas o trabajo futuro

Template de PR recomendado

## Descripción [Resumen breve de los cambios y su propósito] ## Motivación [Enlace a issue/ticket, contexto del problema] ## Cambios realizados - [Lista de cambios principales] ## Screenshots / Videos [Si hay cambios visuales] ## Plan de testing - [ ] Tests unitarios - [ ] Tests de integración - [ ] Test manual ## Checklist - [ ] El código sigue las convenciones del proyecto - [ ] Se han actualizado los tests - [ ] Se ha actualizado la documentación - [ ] No hay warnings nuevos del linter

La revisión de código es la actividad más importante asociada a los Pull Requests. Google, en sus Engineering Practices (google.github.io/eng-practices), publica directrices detalladas que han sido adoptadas como referencia por la industria.

Qué buscar en una revisión

Según las prácticas de ingeniería de Google, un revisor debe evaluar:

1. Diseño: ¿La solución es correcta a nivel arquitectónico? ¿Se integra bien con el sistema existente?
2. Funcionalidad: ¿El código hace lo que dice que hace? ¿Maneja los edge cases?
3. Complejidad: ¿Se puede simplificar? ¿Otro desarrollador lo entendería fácilmente?
4. Naming: ¿Los nombres de variables, funciones y clases son descriptivos?
5. Comentarios: ¿Los comentarios explican el "por qué", no el "qué"?
6. Tests: ¿Hay tests adecuados? ¿Cubren los casos importante y los edge cases?
7. Estilo: ¿Sigue las convenciones del proyecto?

Cómo dar feedback constructivo

El feedback en code review tiene un impacto directo en la cultura del equipo. Investigadores de Microsoft Research (Bosu et al., "Process Aspects and Social Dynamics of Contemporary Code Review", IEEE TSE, 2017) encontraron que los equipos con culturas de code review positivas tienen 33% más retención de desarrolladores.

Feedback constructivo:

• "Considera extraer esta lógica a una función separada para mejorar la legibilidad. ¿Qué opinas?"
• "He visto que el SDK de Google ya maneja este caso. Podríamos usar googleAuth.verify() directamente."
• "Nit: la variable d podría llamarse deliveryDate para mayor claridad."

Feedback no constructivo (evitar):

• "Esto está mal."
• "¿Por qué hiciste esto así?"
• "Reescribe todo."

Niveles de comentarios

Muchos equipos usan prefijos para clasificar la severidad de los comentarios:

Prefijo	Significado	¿Bloquea el merge?
blocker:	Problema que debe corregirse	Sí
suggestion:	Mejora recomendada	No necesariamente
nit:	Detalle menor de estilo	No
question:	Pregunta para entender	No
praise:	Algo que está bien hecho	No

Métricas clave según DORA

El programa DORA (DevOps Research and Assessment) de Google Cloud, documentado en Accelerate (Forsgren, Humble & Kim, IT Revolution Press, 2018), identifica métricas que correlacionan con el rendimiento organizacional:

Métrica	Elite	Alto	Medio	Bajo
Frecuencia de deploy	Bajo demanda	Diario-semanal	Mensual	Cada 1-6 meses
Lead time para cambios	< 1 hora	1 día - 1 semana	1-6 meses	> 6 meses
Tasa de fallos	0-15%	16-30%	16-30%	> 30%
Tiempo de recuperación	< 1 hora	< 1 día	1 día - 1 semana	> 6 meses

Métricas específicas de PRs

Según datos de LinearB (plataforma de engineering metrics), los equipos de alto rendimiento muestran estas características en sus PRs:

• Tamaño de PR: Menos de 200 líneas cambiadas (excluidas líneas generadas)
• Tiempo hasta primera revisión: Menos de 4 horas
• Tiempo de merge: Menos de 24 horas desde la creación
• Número de revisiones antes de merge: 1-2 ciclos de revisión
• Pickup time: Tiempo desde que se asigna un reviewer hasta que empieza a revisar

GitHub

• Modelo de Pull Request (PR)
• GitHub Actions para CI/CD integrado
• CODEOWNERS para asignar revisores automáticamente
• Branch protection rules para exigir revisiones y checks
• GitHub Copilot puede sugerir mejoras en PRs

GitLab

• Modelo de Merge Request (MR)
• GitLab CI/CD integrado nativamente
• Approval rules con múltiples niveles de aprobación
• Merge trains para gestionar múltiples MRs simultáneos

Bitbucket

• Modelo de Pull Request
• Integración profunda con Jira (linking automático)
• Pipelines para CI/CD
• Merge checks configurables

CI/CD en Pull Requests

Cada PR debería activar un pipeline automatizado que ejecute:

1. Linting: Verificar estilo y convenciones de código
2. Tests unitarios: Validar que la lógica funciona correctamente
3. Tests de integración: Verificar que los componentes interactúan bien
4. Build: Compilar el proyecto y verificar que no hay errores
5. Análisis de seguridad: Escanear vulnerabilidades (SAST, dependency scanning)
6. Preview deployment: Desplegar una versión temporal para testing manual

Bots y herramientas de automatización

Herramienta	Función
Dependabot (GitHub)	PRs automáticos para actualizar dependencias
Renovate	Similar a Dependabot, más configurable
Danger	Automatizar reglas de review (tamaño, formato, etc.)
SonarQube	Análisis de calidad de código
Codecov	Reportar cobertura de tests

Para el autor del PR

1. PRs pequeños y enfocados: Un PR debe hacer una sola cosa. Un estudio de Cisco Systems reveló que la efectividad de la revisión cae un 50% cuando el PR supera las 400 líneas (Cohen, "Best Kept Secrets of Peer Code Review", SmartBear).
2. Auto-review antes de publicar: Revisa tus propios cambios en la interfaz del PR antes de pedir revisión.
3. Descripción completa: No hagas que los revisores adivinen qué hace tu PR.
4. Responde al feedback: Contesta todos los comentarios, aunque sea con "Hecho" o "No aplica porque...".
5. Mantén el PR actualizado: Resuelve conflictos con la rama destino regularmente.

Para el revisor

1. Revisa pronto: El tiempo de espera en code review es uno de los mayores bloqueadores de productividad.
2. Sé constructivo: Sugiere alternativas, no solo señales problemas.
3. Distingue bloqueantes de mejoras: No bloquees un PR por preferencias de estilo.
4. Aprende del código: La revisión es una oportunidad de aprendizaje bidireccional.
5. Aprueba cuando sea suficientemente bueno: No busques la perfección, busca que el código sea mejor que antes.

Para el equipo

1. Define CODEOWNERS: Asigna owners a áreas del código para distribuir las revisiones.
2. Establece SLAs de review: Por ejemplo, "toda PR recibe primera revisión en < 4 horas laborales".
3. Usa templates de PR: Estandariza qué información debe incluir cada PR.
4. Branch protection rules: Exige al menos 1 aprobación y que pasen los checks de CI.
5. Retrospectivas sobre el proceso: Revisa periódicamente si el proceso de PRs funciona bien.

¿Cuál es la diferencia entre Pull Request y Merge Request?

Son el mismo concepto con diferente nombre. GitHub usa "Pull Request" y GitLab usa "Merge Request". Ambos representan una solicitud para integrar cambios de una rama a otra. Bitbucket también usa "Pull Request". El nombre "Pull Request" viene de que estás pidiendo al mantenedor que haga git pull de tus cambios.

¿Cuántos revisores debería tener un PR?

La investigación de Microsoft Research (Rigby & Bird, "Convergent Contemporary Software Peer Review Practices", ESEC/FSE, 2013) analizó proyectos de Microsoft, Google, Apache y Linux y encontró que 2 revisores es el número óptimo. Con 1 solo revisor se pierden bugs; con más de 3, la efectividad marginal de cada revisor adicional disminuye drásticamente. Google requiere mínimo 1 aprobación; equipos críticos suelen requerir 2.

¿Qué hacer si un PR lleva días sin revisión?

1. Verifica que el PR tiene un reviewer asignado
2. Envía un recordatorio amable (en el PR o por chat)
3. Revisa si el PR es demasiado grande — PRs grandes se revisan más lento
4. Establece SLAs de review como equipo
5. Considera pair programming como alternativa para cambios urgentes

¿Se puede hacer push directo a main sin PR?

Técnicamente sí, pero la mayoría de equipos profesionales lo prohíben mediante branch protection rules. El push directo a main elimina la revisión de código, la ejecución de CI/CD y la trazabilidad de los cambios. En equipos que usan feature flags, se puede hacer deploy sin activar la funcionalidad hasta la release planificada. Solo debería considerarse para hotfixes extremadamente urgentes, y aun así con restricciones.

¿Cómo gestionar PRs en equipos distribuidos o remotos?

Los equipos distribuidos en diferentes zonas horarias enfrentan el reto del "review latency". Estrategias:

• Revisiones asíncronas: Descripciones detalladas que no requieran aclaración en tiempo real
• Overlap hours: Definir horas de solapamiento para discusiones sincrónicas
• Pairing para cambios complejos: Pair programming virtual reduce la necesidad de review
• Auto-merge con condiciones: Si CI pasa y hay 1+ aprobación, merge automático
• Stacked PRs: Dividir cambios grandes en PRs secuenciales que se pueden revisar independientemente