tag - github release notes

¿Son posibles las solicitudes de extracción dependientes en Github?

Question

Actualmente estoy trabajando en una gran solicitud de extracción. Para mantener las revisiones de código de alguna manera manejables, la idea era dividir la solicitud de extracción completa en partes aisladas, que sin embargo dependen unas de otras.

Un ejemplo sería:

• Solicitud de extracción 1 : Crear interfaces: Interfaz A y B y código de reestructuración
• Solicitud de extracción 2 : Implementación de la interfaz A y pruebas (depende de la solicitud de extracción1)
• Solicitud de extracción 3 : Implementación de la interfaz B y pruebas (depende de la solicitud de extracción2)
• Solicitud de extracción 4 : Prueba mixta de implementaciones (depende de 2 + 3)

¿Hay una manera en Github para archivar las cuatro solicitudes de extracción al mismo tiempo con dependencias?

Answer 1

Por lo que puedo ver, esto es imposible, y en mi opinión es una de las principales desventajas de GitHub en comparación con otras herramientas de revisión de código. Gerrit configura automáticamente las revisiones de código dependientes cuando presiona las confirmaciones que dependen unas de otras, y en Phabricator es más complicado, pero aún así es posible.

También es bueno tener en cuenta que existen muchas formas en que las personas usan las relaciones públicas de GitHub. La forma habitual de colaboración de código abierto es bifurcar un repositorio y enviar una solicitud de extracción de devolución cruzada, pero en otros casos (por ejemplo, dentro de una organización), puede enviar solicitudes de extracción para diffs dentro del mismo repositorio. Creo que dentro de un solo repositorio es más razonable obtener algo similar a las solicitudes de extracción dependientes, ya que puede configurar la estructura commit / branch dentro de ese repositorio.

Aquí hay una publicación de blog que describe cómo obtener algunas ventajas de las solicitudes de extracción dependientes, que creo que requiere que todos los compromisos estén en el mismo repositorio: http://graysonkoonce.com/stacked-pull-requests-keeping-github-diffs-small/

Un resumen:

• Para enviar 5 solicitudes de extracción dependientes, cree una jerarquía de ramas de 5 niveles y envíe cada RP como esa rama basada en la rama anterior.
• Para actualizar la revisión 2 de 5, presione una actualización a la rama 2, luego realice 3 operaciones de combinación para integrar los cambios en las revisiones 3, 4 y 5.
• Debe incluir todos los cambios a la vez, ya que GitHub no admite la actualización de la rama de destino de los RP. En el ejemplo, todas las revisiones de 5 códigos se obtuvieron como un solo compromiso. GitHub ahora admite la actualización de la rama base de un RP, por lo que los RP pueden aterrizarse de una en una.

Ese enfoque parece funcionar bien para los cambios gigantes que se revisan mejor en partes más pequeñas (aunque mantener una jerarquía de ramas de nivel n profundo es un dolor en comparación con algo como git rebase -i ), pero en realidad no permite un " código de canalización de revisión "donde puede tener diferencias dependientes en diferentes etapas de revisión y puede aterrizar las anteriores a medida que se revisan.

Algunos otros recursos de Internet que parecen llamar también la limitación:

https://www.quora.com/Is-there-a-good-system-for-adding-multiple-pull-requests-to-GitHub

https://muffinresearch.co.uk/how-do-you-deal-with-dependent-branches-on-github/

Tengo entendido que las personas que usan las relaciones públicas de GitHub generalmente solo intentan estructurar su flujo de trabajo para no confiar en las revisiones de código dependientes. Algunos ejemplos:

• En lugar de dividir un cambio en pasos incrementales de revisión independiente, envíelo como una revisión de código monolítico que aterrizará todo al mismo tiempo. GitHub aún le permite dividir las revisiones de código en múltiples confirmaciones que el revisor puede ver, pero no pueden ser aprobadas / aterrizadas de forma independiente.
• Trate de estructurar su trabajo para que realice cambios en partes no relacionadas del código y colóquelos en sucursales independientes que pueda usar para enviar RP independientes. Aún puede mantener una sucursal local con todos los cambios aplicados usando cherry-picking u otros enfoques.
• Si tiene un cambio que depende de un RP pendiente, simplemente espere a que el RP sea aceptado y fusionado antes de enviar el nuevo PR. Podría mencionar en alguna parte que tiene otra RP que depende de esa, y tal vez eso motivará al revisor del código para llegar a esa antes.