La tendencia de la rama de "desarrollar" desaparece

He notado algo últimamente mirando algunos proyectos populares en GitHub, que no hay developsucursal. Y, de hecho, la guía GitHub Flow tampoco lo menciona. Según tengo entendido, mastersiempre debe ser totalmente estable y reflejar la producción. Si los desarrolladores están trabajando en ramas de características y luego las fusionan mastercuando están listas, eso significa que hay un período de tiempo en el que las características / arreglos se fusionan mastery la masterrama es realmente más nueva que la producción.

¿No tendría más sentido que el equipo cree ramificaciones de características / arreglos develop, se fusione con eso y luego, cuando la próxima versión esté totalmente lista para su lanzamiento, developse fusione mastery se cree una etiqueta? Imagínese si las personas se están fusionando directamente master, y se informa un error en la producción que se vuelve difícil de solucionar porque la masterbase de código de la rama ha cambiado significativamente. Luego, los desarrolladores solo tienen que decirle al usuario que espere hasta la próxima versión para ver el problema resuelto.

EDITAR: Esta pregunta es diferente a "ramificarse o no ramificarse". Se dirige específicamente a las personas que se alejan del uso de la rama de desarrollo y las razones que la rodean, ya que se promocionó como la mejor práctica durante mucho tiempo.

Proviene de la mentalidad de CI donde hay integración varias veces al día.

Hay pros y contras de ambos.

En nuestro equipo también hemos abandonado la rama de desarrollo, ya que consideramos que no proporcionó ningún beneficio adicional, sino algunos inconvenientes. Hemos configurado nuestro software CI (Teamcity) para compensar los inconvenientes:

1. Habilitar la implementación de una confirmación específica. En otras palabras: no desplegamos una sucursal. Implementamos un compromiso.
2. Podemos implementar maestro o ramas comenzando con un hotfix / prefijo.

La razón por la que esto funciona es porque todas las solicitudes de extracción contienen código potencialmente liberable, pero esto no significa que implementemos todas las confirmaciones en el maestro.

La razón principal por la que abandonamos la rama de desarrollo es porque tiende a ser demasiado grande y demasiado lenta para ver lo que realmente contenía. Si hemos implementado algo un poco prematuramente, simplemente ramificamos una rama de revisión y la implementamos directamente.

Una rama de desarrollo es más importante si su proceso de lanzamiento es complejo y necesita tener candidatos de lanzamiento serios.

Por ejemplo, imagine que está escribiendo software que es firmware en automóviles. Esto es ... no trivial de solucionar y es probable que cualquier versión tenga un conjunto completo de pruebas de integración / no CI ejecutadas en hardware real.

En ese caso, puede tener más sentido aislar un "candidato de liberación" en una rama no maestra (como "desarrollar"). Eso permite que su equipo que ejecuta esas pruebas tenga una rama en la que fusionar características.

Webapps u otro software fácilmente actualizado no tienen esta restricción.

Sin embargo, tenga en cuenta que:

• Muchos proyectos (¿la mayoría?) En github no tienen este tipo de restricción
• Un "maestro" principal tiene el mismo propósito
• Un flujo de trabajo de "hacer un RP frente a un maestro" es mucho más universal que "hacer un RP contra una rama que no conoces inmediatamente en este repositorio"

Hay dos filosofías que he visto en proyectos, y creo que la elección es solo cuestión de gustos:

1. Designe a 'maestro' como el lanzamiento de producción y desarrolle en una rama de 'desarrollo'.

2. Desarrolle en 'maestro' y tenga una rama con un nombre diferente para lanzamientos de producción estables. Esto tiene aún más sentido si su proyecto tiene varias ramas de lanzamiento a la vez (p. Ej., El preferido actual es Release-1.8, pero también sigue manteniendo Release-1.7).

Ambos son enfoques comunes y tienen sus pros y sus contras.

Los lanzamientos a producción se pueden etiquetar, por lo que la situación que se lanzó siempre se puede reproducir sin dedicar una rama completa para este propósito.

Si se encuentra un error crítico en la producción en un momento en que el maestro no se puede liberar, entonces es bastante fácil verificar la etiqueta e iniciar una nueva rama "hotfixes-for-release-1.2.0" desde allí. Pero eso debería ser bastante raro.

La mayoría de las veces en nuestras aplicaciones web, master ha cambiado desde la última versión, pero no de manera muy significativa, por lo que simplemente podemos hacer una nueva versión de master que tenga la solución. Ayuda a hacer lanzamientos muy frecuentes de todos modos.

Si los desarrolladores están trabajando en ramas de características y luego las fusionan en maestras cuando terminan, eso significa que hay un período de tiempo en el que las características / arreglos se fusionan mastery la masterrama es realmente más nueva que la producción.

...

Imagínese si las personas se fusionan directamente en master, y se informa un error en la producción que se vuelve difícil de solucionar porque la base de código de la rama master ha cambiado significativamente.

Eso no es Github Flow.

Este es el proceso de implementación / fusión de Github Flow, de acuerdo con su enlace:

Desplegar

Una vez que su solicitud de extracción ha sido revisada y la sucursal pasa sus pruebas, puede implementar sus cambios para verificarlos en producción. Si su sucursal causa problemas, puede revertirla implementando el maestro existente en producción.

Unir

Ahora que sus cambios se han verificado en producción, es hora de fusionar su código en la rama maestra.

(El énfasis es mío)

En otras palabras, masternunca se adelantará a la producción. Del mismo modo, mastersiempre estará en un estado estable y liberable (aparte de los errores no descubiertos), ya que todo se revisa, se prueba y se lanza a producción antes de fusionarse master.

El problema que veo es que Git / Hub flow deploy / merge asume que una característica se está desarrollando / probando / fusionando / implementando a la vez, y a menudo, en mi experiencia, este no es el caso. Si fusionamos una característica a la vez, hay una mayor posibilidad de problemas de regresión, que solo se encuentran después de que las características se fusionen para dominar y posiblemente en producción.

Es necesario que haya una forma de probar varias funciones, combinar varias funciones e implementarlas. He estado usando una 'rama de paquete' (una rama creada desde el maestro con ramas de características listas para prueba fusionadas en ella) que se implementa en qa / uat. Las correcciones durante uat ocurren solo en la rama de características, y esas se vuelven a fusionar en la rama del paquete. Después de que se aprueba una subsección de la rama del paquete, solo las características aprobadas dentro del paquete se solicitan de extracción para dominar, y el ciclo es continuo.

Lo uso con Gitflow, pero estoy pensando en usarlo para el flujo de GitHub. El tema QA / UAT de muchas características a la vez parece significativo. Otro problema con el flujo de GitHub es que asume todos los desarrolladores sr, y ese no es siempre el caso.

Preferiría usar el flujo de GitHub debido a su simplificación. Con un paquete como función, creo que estaría mejor preparado. Es posible que el paquete sea similar al lanzamiento; Sin embargo, todavía estoy reflexionando sobre esto también.

Otro problema es que el proceso de solicitud de extracción ocurre al final antes de fusionarse con master; sin embargo, a veces desea revisar el código antes de la prueba de qa comercial, por lo tanto, mucho antes de la fusión