Flujo de trabajo de pull requests en GitHub

Una Pull Request (PR) es una propuesta para fusionar una rama con otra. En GitHub, crea un hilo de conversación donde el equipo revisa el código, deja comentarios, solicita cambios y, finalmente, aprueba la fusión.

Después de enviar una rama de funcionalidad a GitHub, aparece un banner amarillo que ofrece comparar las ramas y crear una PR. Haga clic en él o vaya a Pull Requests → New pull request y seleccione las ramas.

Una buena descripción de una PR explica qué cambió y por qué. Incluya una captura de pantalla si hay cambios en la interfaz. Enlace la incidencia relacionada. Describa cómo la probó. El lector no debería tener que leer el código para entender la intención.

Asigne revisores concretos de su equipo. Recibirán una notificación y podrán aprobar, solicitar cambios o comentar. La mayoría de los equipos exige al menos una aprobación antes de fusionar.

Los comentarios aparecen en línea sobre las líneas modificadas. Los revisores pueden pedir aclaraciones, sugerir otro enfoque o aprobar. Responda a cada comentario, ya sea con un cambio en el código o explicando por qué no lo hará.

Cuando un revisor solicita cambios, envíe nuevos commits a la misma rama. La PR se actualiza automáticamente. Resuelva cada conversación haciendo clic en «Resolver conversación» después de atenderla.

Abra una PR como borrador para indicar que es un trabajo en curso. Las PR en borrador permiten revisiones y conversaciones, pero no se pueden fusionar accidentalmente. Cámbiela a lista para revisión cuando esté completa.

Cuando main avance durante la revisión, cambie la base de su rama sobre la versión más reciente de main para evitar conflictos y asegurarse de que sus cambios funcionan con el código nuevo.

GitHub ofrece tres estrategias de fusión: Commit de fusión (conserva todos los commits), Squash and merge (un commit por PR, con un historial limpio en main) y Rebase and merge (lineal y sin commit de fusión). Normalmente, los equipos eligen una estrategia para mantener la coherencia.

Proteja main exigiendo una revisión de PR, comprobaciones de estado aprobadas (CI) y prohibiendo los envíos directos. Configúrelo en GitHub → Settings → Branches.

Mantenga las PR pequeñas y centradas. Una PR por cada funcionalidad o corrección. Las PR grandes son difíciles de revisar. Responda a los comentarios de revisión en el plazo de un día. Agradezca a los revisores. Sea amable: la revisión de código es una oportunidad de aprendizaje, no una auditoría.

¿Qué debe incluir una buena descripción de una PR?

Envíe la rama de funcionalidad → abra una PR con una descripción clara → solicite revisores → atienda los comentarios con nuevos commits → mantenga la rama actualizada mediante rebase → obtenga la aprobación → fusione. Mantenga las PR pequeñas, centradas y bien descritas. Las reglas de protección de ramas garantizan la calidad en main.