Las solicitudes de incorporación de cambios son propuestas para combinar los cambios de código en un proyecto. Una solicitud de incorporación de cambios es GitHubla característica de colaboración clave, lo que le permite analizar y revisar los cambios antes de combinarlos. Esto ayuda a los equipos a trabajar juntos, detectar problemas al principio y mantener la calidad del código.
Visualización de las solicitudes de incorporación de cambiosTrabajar con solicitudes de incorporación de cambios.
Una solicitud de extracción reúne el contexto que los revisores necesitan para comprender un cambio. Este contexto se organiza en pestañas:
- La pestaña Conversación muestra la descripción, la escala de tiempo, los comentarios y las revisiones.
- En la pestaña Confirmaciones se muestra cómo cambió la rama de solicitud de incorporación de cambios a lo largo del tiempo.
- La pestaña Comprobaciones muestra pruebas automatizadas, compilaciones y otras validaciones.
- La pestaña Archivos modificados muestra la diferencia que usan los revisores para comprender los cambios propuestos.
- La pestaña Resultados muestra los resultados automatizados de la revisión de código, como las alertas de análisis de código, de los cambios propuestos.
Por separado de las pestañas, el estado de combinación resalta los bloqueadores, las aprobaciones que faltan y otros requisitos antes de la combinación. Aparece en el encabezado de la solicitud de incorporación de cambios y en el cuadro de combinación.
Juntas, estas vistas ayudan a los autores y revisores a analizar el cambio, realizar un seguimiento de los comentarios y decidir cuándo la solicitud de incorporación de cambios está lista para combinarse.
Solicitudes de extracción en borrador
Al crear una solicitud de incorporación de cambios, puede optar por convertirlo en una solicitud de incorporación de cambios de borrador. Los borradores de solicitudes de cambios no se pueden combinar y no se solicita automáticamente a los propietarios del código que las revisen. Los borradores son útiles cuando desea compartir el trabajo en curso sin solicitar revisiones formalmente.
Cuando estés listo para obtener retroalimentación sobre tu solicitud de extracción, puedes marcar tu borrador de solicitud de extracción como listo para revisión. Con esto, solicitarás las revisiones de cualquier propietario de código en cuestión. Puede convertir una solicitud de incorporación de cambios a un borrador en cualquier momento. Consulte Cambiar la etapa de un pull request.
Referencias de solicitud de incorporación de cambios y ramas de combinación
Al abrir una solicitud de incorporación de cambios, GitHub crea referencias temporales de Git que apuntan a la rama principal de la solicitud de incorporación de cambios y, cuando sea posible, a un resultado de combinación simulado. Estas referencias ayudan a GitHub y a las integraciones a evaluar la solicitud de extracción sin modificar la rama base.
Para la mayoría de los colaboradores, estas referencias quedan en segundo plano. Son especialmente relevantes cuando estás creando automatizaciones, depurando el comportamiento de CI o consultando localmente el estado de una solicitud de incorporación de cambios. Para obtener información sobre cómo GitHub Actions usa la rama de combinación, consulte Eventos que desencadenan flujos de trabajo.
Diferencias entre confirmaciones en las páginas de comparación y de solicitudes de cambios
Las páginas de comparación y las páginas de solicitudes de extracción pueden calcular los archivos cambiados a partir de distintas bases de fusión. Como resultado, las mismas ramas a veces pueden mostrar diferencias diferentes en cada lugar.
Esto suele ser importante cuando la rama base ha cambiado desde que se creó la solicitud de incorporación de cambios. Las páginas de solicitud de incorporación de cambios se centran en lo que introdujo la solicitud de incorporación de cambios, mientras que las páginas de comparación reflejan la comparación actual entre dos referencias.
Modelos de desarrollo colaborativo
El modo en que usas las solicitudes de extracción depende del tipo de modelo de desarrollo que uses en tu proyecto. Puedes utilizar el modelo de bifurcación y extracción o el modelo de repositorio compartido.
Modelo de bifurcación y extracción
En el modelo de bifurcación y extracción, cualquier persona puede bifurcar un repositorio existente ("ascendente") si tiene acceso de lectura y el propietario del repositorio ascendente lo permite. Tenga en cuenta que una bifurcación y su cadena ascendente comparten los mismos datos de Git. Esto significa que todo el contenido cargado en una bifurcación es accesible desde el repositorio ascendente y todas las demás bifurcaciones de ese repositorio ascendente.
No necesita permiso del repositorio ascendente para insertar en una bifurcación que ha creado. Opcionalmente, puedes permitir que cualquier usuario con acceso de inserción al repositorio ascendente realice cambios en la rama de tu solicitud de cambios. Este modelo es popular con proyectos de código abierto, ya que reduce la fricción de los nuevos colaboradores y permite a las personas trabajar de forma independiente sin coordinación inicial.
Sugerencia
Para más información sobre el código abierto, en concreto cómo crear e incrementar un proyecto de código abierto, hemos creado Guías de código abierto que le ayudarán a desarrollar una comunidad de código abierto activa.También puede tomar un curso gratuito de GitHub Skills sobre el mantenimiento de comunidades de código abierto.
Modelo de repositorio compartido
En el modelo de repositorio compartido, los colaboradores tienen permiso de envío a un único repositorio compartido y crean ramas temáticas cuando necesitan hacer cambios. Las solicitudes de incorporación de cambios son útiles en este modelo porque inician la revisión del código y la explicación general sobre un conjunto de cambios antes de que los cambios se combinen en la rama de desarrollo principal. Este modelo es más común con equipos pequeños y organizaciones que colaboran en proyectos privados.