¿Qué es un pull request en GitHub y para qué sirve revisarlo?

Publicado el 2026-10-20 por frfrand

Qué es un pull request, cómo proponer cambios, revisar diferencias, ejecutar pruebas y hacer merge sin perder el control del proyecto.

Un pull request es una propuesta para integrar cambios de código de una rama en otra, normalmente después de discutirlos y revisarlos. En GitHub, reúne la descripción del cambio, los archivos modificados, comentarios y verificaciones automáticas.

No es lo mismo que git pull, que es un comando para traer cambios. Un pull request es una función de colaboración de plataformas como GitHub.

¿Por qué hace falta?

Imaginá una tienda online donde tres personas trabajan a la vez. Una modifica el carrito, otra mejora los correos y otra ajusta los pagos. Si todas publican directamente sobre la rama principal, puede resultar difícil saber qué provocó un error.

Las ramas permiten trabajar por separado. El pull request ofrece un lugar para comprobar que un cambio funciona y es comprensible antes de integrarlo.

Cómo funciona en la práctica

1. Creás una rama para agregar, por ejemplo, la recuperación de contraseñas.
2. Modificás archivos y guardás los avances mediante commits.
3. Subís esa rama al repositorio remoto.
4. Abrís un pull request que propone integrarla a la rama principal.
5. Describís el problema, la solución y cómo probarla.
6. Otras personas revisan los cambios y pueden aprobarlos o pedir correcciones.
7. Cuando cumple los requisitos del proyecto, se realiza el merge.

Si el revisor encuentra un problema, hacés otro commit en la misma rama y el pull request se actualiza. No necesitás empezar otra propuesta desde cero cada vez.

¿Qué debería revisar alguien?

Lo primero es entender qué problema se intenta resolver. Después, comprobar que la solución no rompe funcionalidades existentes.

En una pantalla de pagos, por ejemplo, no basta con ver que el botón se muestra bien. Hay que revisar importes, autorización, tratamiento de fallos y posibles cobros repetidos.

También pueden revisarse dependencias, rendimiento, pruebas, seguridad y claridad del código. Los cambios pequeños y concretos suelen ser más fáciles de analizar que un pull request con cien temas mezclados.

¿Qué son los checks verdes?

GitHub permite ejecutar pruebas automáticas, compilaciones y verificaciones mediante herramientas de integración continua. Un check verde indica que esos controles pasaron, no que el código esté garantizado contra todos los errores.

Para proyectos importantes conviene combinar pruebas automáticas con revisiones enfocadas. La profundidad adecuada depende del riesgo del cambio.

¿Qué significan comentar, aprobar y pedir cambios?

Un comentario expresa una observación o pregunta. Una aprobación indica que el revisor considera aceptable el cambio. Solicitar cambios señala que hay aspectos que deberían corregirse antes de integrar.

Según las reglas del repositorio, puede exigirse un número mínimo de aprobaciones o controles automáticos aprobados.

¿Qué pasa cuando aparece un conflicto?

Git puede no saber combinar dos cambios en las mismas líneas. Eso no significa que el repositorio esté roto. Hay que decidir qué comportamiento final corresponde, resolver el conflicto y volver a probar.

No borres los marcadores de conflicto al azar para que Git deje de quejarse. El objetivo es conservar la lógica correcta, no silenciar el mensaje.

¿Tiene sentido si trabajo solo?

Sí, en ciertos proyectos. Incluso sin equipo, abrir un pull request antes de publicar permite revisar el alcance y documentar por qué hiciste un cambio.

Pero no todo necesita un proceso burocrático. Corregir un texto en un prototipo puede requerir menos pasos que modificar autenticación o migrar datos de clientes.

Cómo escribir una buena descripción

Explicá qué cambia, por qué cambia y cómo se prueba. Indicá si hay migraciones, nuevas variables de entorno o puntos que todavía requieren atención. Adjuntá capturas si la interfaz cambió.

«Arreglos varios» no ayuda a quien revisa hoy ni a quien intenta entender el historial dentro de seis meses.

¿Dónde encaja ArduMaker?

Los proyectos desplegados desde Git en VPS de ArduMaker pueden beneficiarse de una revisión previa en GitHub: así el equipo comprueba los cambios antes de activar un nuevo despliegue. El pull request es parte del proceso del repositorio, no una garantía automática de calidad.

En resumen: un pull request convierte una modificación en una propuesta verificable, discutible y reversible dentro del flujo de trabajo del equipo.

Fuentes: Pull requests según GitHub · Guía de revisión · Ramas y merge explicados.