Aprobar / Obtener aprobación: qué es, aprobación y code review en Git

Qué es la aprobación de pull request

La aprobación es una revisión positiva de un pull request, que significa que el revisor ha verificado el código, no ha encontrado problemas críticos y considera que los cambios están listos para la fusión. En la interfaz de GitHub, esto es el botón verde «Approve» en la página del PR. Tras la aprobación, el autor (o cualquier miembro con permisos de escritura) puede realizar el merge.

El proceso de aprobación forma parte de las Branch Protection Rules. Los propietarios del repositorio configuran los requisitos obligatorios: número mínimo de aprobaciones (por ejemplo, 1 o 2), quién puede aprobar (propietarios del código, miembros del equipo) y si el PR debe ser aprobado nuevamente tras cambios (Dismiss stale reviews). Sin configuración de reglas, la aprobación es opcional, pero en equipos profesionales es obligatoria.

GitLab utiliza un mecanismo similar llamado Approval Rules. En GitLab se puede configurar cuántas aprobaciones se requieren de diferentes grupos (por ejemplo, 2 de desarrolladores backend y 1 de DevOps). Tras recibir todas las aprobaciones obligatorias, el PR se desbloquea automáticamente para el merge siempre que el pipeline CI/CD esté en verde.

Tipos de revisión: Approve, Request Changes, Comment

GitHub y GitLab tienen tres tipos de revisión que un revisor puede dejar en un pull request. Cada tipo tiene un estado y consecuencias diferentes para el proceso de fusión. Approve es verde, Request Changes es rojo, Comment es gris neutro. La elección depende de la calidad del código y de la preparación de los cambios para su aceptación.

Approve — el revisor confirma: el código está escrito correctamente, cumple con los estándares, no contiene errores evidentes y puede fusionarse. Approve no significa que el código sea perfecto — solo que es suficientemente bueno para producción. Si hay comentarios menores (estilo, nomenclatura), pueden dejarse como comentarios sin bloquear el PR.

Request Changes — el revisor encuentra problemas que deben corregirse antes del merge: errores lógicos, vulnerabilidades, violaciones de arquitectura, falta de pruebas. Tras Request Changes, el PR se bloquea y se requiere una nueva aprobación del mismo revisor para desbloquearlo (si la opción Dismiss stale reviews está activada en nuevos commits).

• Approve — el código está listo para fusionarse, se puede merge después de que pase el CI.
• Request Changes — correcciones obligatorias, el PR está bloqueado hasta una nueva revisión.
• Comment — observación general o sugerencia sin bloquear el PR.

Configuración de reglas de aprobación en el repositorio

Las Branch Protection Rules son el mecanismo de GitHub para controlar la calidad de las fusiones. Se configuran en Settings → Branches para cada rama protegida (main, develop, release/*). Parámetros principales: número de aprobaciones obligatorias, propietarios del código (CODEOWNERS), verificación obligatoria de CI/CD y prohibición de push sin PR.

El parámetro Dismiss stale pull request approvals elimina automáticamente las aprobaciones si se añade un nuevo commit al PR. Esto garantiza que los revisores aprueben exactamente la versión del código que se fusionará. Sin esta configuración, el autor podría añadir nuevo código tras la aprobación y este llegaría a main sin una nueva verificación.

CODEOWNERS — un archivo en la raíz del repositorio que asigna responsables de diferentes directorios. Si un PR afecta archivos que pertenecen a un propietario del código, su aprobación se vuelve obligatoria. CODEOWNERS permite distribuir áreas de responsabilidad: los desarrolladores iOS responden por los archivos Swift, DevOps por las configuraciones de Docker, los testers por los escenarios de prueba.

# Archivo CODEOWNERS de ejemplo en la raíz del repositorio

# Los desarrolladores de iOS son dueños del código Swift
*.swift @team/ios-developers

# DevOps es dueño de la configuración de CI/CD
.github/workflows/* @devops-team

# Los ingenieros de QA revisan las pruebas
**/tests/* @qa-engineers

# Propietarios predeterminados para todo lo demás
* @tech-leads

Code review antes de la aprobación: qué verificar

El code review antes de la aprobación es una verificación sistemática del código, no un vistazo rápido al diff. Una revisión de calidad incluye la verificación de la arquitectura, la lógica, el estilo, las pruebas y la seguridad. Sin esta verificación, la aprobación se convierte en una formalidad y no en una herramienta de control de calidad.

Qué se verifica primero: la lógica de los cambios — si el código resuelve la tarea, si hay efectos secundarios, si el manejo de casos límite es correcto. Pruebas — si las nuevas pruebas cubren todos los escenarios, si las pruebas existentes pasan tras los cambios. Seguridad — si hay inyecciones SQL, XSS, fugas de datos sensibles.

Qué no debe ser objeto de revisión: el estilo de formato (para eso existen linters y formateadores), las decisiones arquitectónicas tomadas previamente (se discuten antes de escribir código). Si una revisión supera las 400 líneas o toma más de una hora, es señal de que la tarea es demasiado grande y requiere descomposición. Las mejores prácticas de revisión — porciones de 200–400 líneas en un plazo de 24 horas desde la creación del PR.

• Lógica — corrección de la solución, manejo de errores, casos límite.
• Pruebas — cobertura de nuevos escenarios, pruebas existentes pasando, sin pruebas flaky.
• Seguridad — ausencia de inyecciones, escape de salida, control de acceso a datos.
• Rendimiento — eficiencia de algoritmos, consultas excesivas, fugas de memoria.
• Documentación — si la documentación está actualizada, si los comentarios en secciones complejas son claros.

Flujo de trabajo con aprobación en equipo

Un flujo de trabajo típico con aprobación en un equipo de 5–10 desarrolladores se ve así: un desarrollador crea un PR, asigna revisores (generalmente 1–2 personas del equipo o propietarios del código), CI/CD ejecuta verificaciones automáticas. Tras recibir todas las aprobaciones obligatorias y un CI verde, el autor realiza el merge. El tiempo desde la creación del PR hasta el merge promedia de 2 horas a 2 días según la complejidad.

GitHub Actions permite automatizar el merge tras la aprobación. Si las reglas de rama están configuradas, GitHub bloquea el merge hasta que se cumplan todas las condiciones. Algunos equipos usan bors-ng o Mergify — bots que fusionan automáticamente los PR tras recibir todas las aprobaciones y pasar el CI. Esto acelera el proceso y elimina el factor humano en los merges.

Un enfoque moderno es trunk-based development con ramas de corta duración. En este flujo, la aprobación debe obtenerse en pocas horas, de lo contrario la tarea se considera obsoleta y requiere resincronización con main. Los equipos con alta cultura de revisión buscan un tiempo de aprobación de no más de 4 horas laborables.

Errores en la aprobación y cómo evitarlos

El error más común es la aprobación formal sin revisión real del código. Cuando el PR es grande o la fecha límite está cerca, el revisor puede hacer clic en Approve sin examinar los cambios. Esto devalúa todo el proceso de code review. Solución: establecer un límite en el tamaño del PR (no más de 400 líneas) y usar herramientas de análisis de código (SonarQube, CodeClimate) para la verificación automática.

El segundo error es la aprobación excesivamente estricta. Esperar un código perfecto bloquea el desarrollo. Los revisores a veces exigen corregir comentarios estilísticos que no afectan la calidad. Solución: dividir claramente entre comentarios obligatorios (bloqueantes) y sugerencias opcionales (comentarios). GitHub permite especificar explícitamente si un comentario es bloqueante.

El tercer error es la aprobación sin verificar CI/CD. Incluso si el código parece correcto, podría no compilar o fallar en las pruebas. Las Branch Protection configuradas bloquean automáticamente el merge con CI rojo, pero algunos equipos desactivan esta protección por rapidez. Solución: verificar siempre el estado del CI antes de aprobar y nunca aprobar un PR con un pipeline rojo.

• Aprobación formal — ausencia de revisión real del código. Solución: límite de 400 líneas por PR.
• Excesivo rigor — bloqueo por comentarios estilísticos. Solución: dividir en bloqueantes y opcionales.
• Ignorar CI — aprobación con pipeline rojo. Solución: verificar siempre el estado de las pruebas.
• Asignación del autor — aprobación por el autor del PR. Solución: configurar Branch Protection contra el autor.