Pull Requests: pedir revisión antes de mergear

Ya sabes crear branches, trabajar en ellas y fusionarlas con git merge. Pero en un equipo profesional, NO fusionas directamente. Haces algo antes: pides que alguien revise tu trabajo. Eso es un Pull Request (PR) — una petición formal de "he terminado mi cambio en esta branch, ¿alguien puede revisarlo antes de que entre en main?". Es como enviar un borrador a tu editor antes de publicar un artículo.

Los Pull Requests son probablemente la innovación más importante de GitHub para la cultura de desarrollo de software. Antes de los PRs, el código se revisaba (si es que se revisaba) por email, enviando parches como archivos adjuntos. Era lento, caótico y se perdía contexto. GitHub creó una interfaz visual donde puedes ver exactamente qué cambió, comentar línea por línea, pedir modificaciones y aprobar el merge. Transformó la revisión de código de un dolor a una conversación productiva.

### Por qué el code review importa (historia real)

En 2019, un equipo donde yo era tech lead tenía un junior brillante que escribía código rápido pero con un problema: no manejaba casos edge. Un viernes por la tarde, subió directamente a main un pipeline de transformación de datos sin revisión. El lunes, descubrimos que cuando un campo de dirección tenía caracteres especiales (ñ, ü, acentos), el pipeline crasheaba silenciosamente y descartaba esos registros. Perdimos 3 días de datos de clientes latinoamericanos. Desde ese día, la regla fue inquebrantable: nada entra a main sin un PR aprobado. NADA.

### Anatomía de un Pull Request

Un PR en GitHub tiene estas partes:

• ▹Título: resumen de una línea de qué hace el cambio (como un commit message)
• ▹Descripción: contexto detallado — qué, por qué, cómo probarlo, qué impacto tiene
• ▹Diff (archivos cambiados): vista línea por línea de lo que añadiste, modificaste o borraste
• ▹Comentarios: conversación entre autor y revisores, tanto generales como en líneas específicas
• ▹Checks: tests automáticos, linting, builds que se ejecutan al crear el PR
• ▹Reviewers: personas asignadas para revisar el código
• ▹Labels: etiquetas como "bug", "feature", "breaking-change"

### Crear tu primer Pull Request

El flujo es: 1) trabajas en tu branch local, 2) la subes a GitHub con git push, 3) creas el PR desde la web de GitHub (o con GitHub CLI). Vamos paso a paso:

1# 1. Asegúrate de que tu branch está subida a GitHub
2git switch feature/exportar-json
3git push -u origin feature/exportar-json
4
5# 2. Crear el PR desde la terminal (con GitHub CLI)
6gh pr create --title "feat: módulo de exportación a JSON" \
7  --body "## Qué hace
8- Añade exportar.py con función para exportar datos a JSON
9- Soporta exportar con indentación configurable
10
11## Cómo probarlo
12python exportar.py --input datos.csv --output resultado.json
13
14## Notas
15Primera iteración. Falta manejo de errores."
16
17# GitHub te da el URL del PR creado.
18# También puedes crearlo desde github.com: verás un banner
19# "Compare & pull request" después de hacer push.

Si prefieres la web (que es como la mayoría empieza): después de hacer push, ve a tu repo en github.com. Verás un banner amarillo diciendo que tu branch tiene commits recientes y un botón "Compare & pull request". Haz click, rellena título y descripción, y click en "Create pull request".

### Cómo escribir una buena descripción de PR

La diferencia entre un PR profesional y uno de principiante está en la descripción. Un PR con descripción "cambios" es una falta de respeto a los revisores. Un buen PR explica el contexto para que el revisor entienda TU decisión sin tener que adivinar:

1# ❌ MAL - No dice nada
2# Título: "updates"
3# Descripción: "fixed stuff"
4
5# ✅ BIEN - El revisor entiende todo en 30 segundos
6# Título: "fix: manejar valores NULL en campo dirección"
7# Descripción:
8# ## Problema
9# El pipeline crashea cuando el campo "direccion" es NULL
10# en la tabla clientes_raw. Afecta a ~200 registros/día.
11#
12# ## Solución
13# Añadido .fillna("Sin dirección") antes de la transformación.
14# Los registros sin dirección ahora se procesan con valor por defecto.
15#
16# ## Testing
17# - Añadido test con fixture que incluye NULLs
18# - Verificado con datos de producción del lunes (tenía 47 NULLs)
19#
20# ## Impacto
21# Cero registros descartados. Pipeline no crashea.

### Revisar un Pull Request

Cuando eres el revisor, tu trabajo es: 1) entender qué hace el cambio (lee la descripción), 2) revisar el código línea por línea buscando problemas, 3) dejar comentarios constructivos, 4) aprobar o pedir cambios. En GitHub, vas a la pestaña "Files changed" del PR y ves el diff completo. Puedes hacer click en cualquier línea y dejar un comentario.

• ▹Approve: "todo bien, aprobado para mergear" (botón verde)
• ▹Request changes: "hay cosas que arreglar antes de mergear" (botón rojo)
• ▹Comment: "tengo preguntas pero no bloqueo el merge" (neutral)

### El ciclo de vida de un PR

### Mergear un PR: las tres opciones

Cuando un PR está aprobado, GitHub te da tres formas de mergearlo. Cada una deja un historial diferente:

• ▹Merge commit (por defecto): crea un commit de merge con dos padres. El historial muestra claramente que hubo una branch. Ideal para equipos que quieren ver la historia completa.
• ▹Squash and merge: aplasta todos los commits de la branch en UNO solo y lo pone en main. Historial más limpio, pero pierdes los commits intermedios. Ideal para PRs con muchos commits "wip" o "fix typo".
• ▹Rebase and merge: reescribe los commits de tu branch como si hubieran sido hechos directamente en main. Historial lineal, sin merge commits. Más avanzado — evítalo al principio.

### Buenas prácticas de code review

El code review es una habilidad social tanto como técnica. He visto equipos donde el review se convierte en una guerra de egos, y equipos donde es la herramienta más valiosa de aprendizaje. La diferencia está en la actitud:

• ▹Como AUTOR: no te lo tomes personal. Los comentarios son sobre el código, no sobre ti. Responde a cada comentario, incluso si es para decir "hecho" o "buena idea, lo cambio".
• ▹Como REVISOR: sé específico y constructivo. No "esto está mal" → sí "esto podría fallar si el input es vacío, ¿consideraste ese caso?". Sugiere alternativas, no solo señales problemas.
• ▹Mantén los PRs pequeños. Un PR de 2000 líneas no lo revisa nadie bien. Ideal: 100-400 líneas. Si tu cambio es grande, divídelo en PRs secuenciales.
• ▹Responde rápido. Un PR que espera revisión 3 días bloquea al autor. Intenta revisar en menos de 24h.
• ▹Usa comentarios de "nit" (nitpick) para cosas menores que no bloquean el merge: estilo, nombres, sugerencias opcionales.

### Branch protection rules: automatizar la disciplina

GitHub permite configurar "Branch protection rules" para main. Estas reglas automatizan las buenas prácticas para que nadie pueda saltárselas — ni siquiera el jefe:

• ▹Require pull request reviews: nadie puede mergear sin al menos 1 aprobación
• ▹Require status checks to pass: los tests automáticos deben pasar antes del merge
• ▹Require up-to-date branch: tu branch debe tener los últimos cambios de main
• ▹Do not allow bypassing: ni siquiera los admins pueden saltarse las reglas

Configurar branch protection rules es de las primeras cosas que hago en un proyecto nuevo. Es como poner un candado en la puerta de producción: solo entras si tienes la llave (PR aprobado + tests pasando).