Pregunta ¿Por qué es una mala idea fusionar ramas de características en ramas de lanzamiento?


Hemos adoptado el modelo de ramificación propuesto por Vincent Driessen y hacemos casi todo lo que él ha descrito en su artículo.

Solo cuando se trata de manejar ramas de liberación nos desviamos un poco.

Vincent propone desarrollar características en ramas que se ramifican desde el desarrollador. Cuando se decide qué características entran en la próxima versión, se fusionan de nuevo en el desarrollador y se crea una rama de publicación a partir de ella.

Después de eso, la rama de características solo debe usarse para probar y corregir errores. Cuando el lanzamiento se implementa en vivo, la rama de lanzamiento se fusiona de nuevo en desarrollador y maestro.

Lo que hacemos en su lugar es fusionar las características directamente en la rama de lanzamiento: realease branch modelling

Siento que esta no es la forma en que debería hacerse y estoy tratando de pensar en casos en los que esto podría complicar las cosas.

Uno que puedo pensar es el siguiente:

Digamos un nuevo Característica c está construyendo sobre Característica a, que ya está fusionado en una rama de lanzamiento. Primero tengo que fusionar la rama de lanzamiento en el desarrollador para poder crear un nuevo Característica c rama del desarrollador.

¿Hay otros casos en los que este modelo de ramificación podría complicar las cosas?


7
2017-07-15 12:48


origen


Respuestas:


Un caso en el que podría pensar, donde esto puede hacer que las cosas se compliquen es que comenzará a bloquear el desarrollo posterior.

Considere que está desarrollando una característica A, que irá inmediatamente en su próximo lanzamiento. Ahora hay otro equipo de desarrollo que trabajará en la característica B, que depende en gran medida de la característica A, pero debe estar en lanzamiento solo después de un par de sprints. Entonces, obviamente ramificaremos la característica B de la característica A.

Ahora, encuentra un error en la característica A, su lanzamiento para la característica A se acerca rápidamente, tiene dos opciones, un arreglo en caliente / pirateo o un factor de corrección y corrección del código.

Con el tiempo como restricción, es prudente tener una solución caliente, pero teniendo en cuenta el futuro necesitamos un reajuste y una solución correctos.

Feliz noticia es que podemos ir por ambos.

Con su estrategia (según tengo entendido) su rama de publicación, recibirá todos los parches y correcciones (contiene 5+ commits) ya que no puede cometer nada de eso para mostrar A (si es estricto en las políticas). Tenga en cuenta la cantidad de correcciones que tendrá esta versión si tiene más de 10 funciones a la vez.

Pero con la estrategia de Vincent Driessen siempre hay una rama de desarrollo como un alijo entre su función y versión, por lo que para esas correcciones se puede fusionar de nuevo a la rama de desarrollo y luego ramificar hacia allí para las soluciones y luego volver al desarrollo y luego a lanzamiento. Y tiene la ventaja de no tener los hacks / hot-fixes en ninguna parte de su rama de características. Las características adicionales basadas en la función pueden continuar en paralelo. Y puede abandonar las ramas de las revisiones o eliminarlas del historial. Este es solo un punto de vista y probablemente puedas defender tu estrategia en este caso. Estoy abierto para futuras discusiones y correcciones en mi respuesta :)

Y aquí hay una imagen bastante desagradable que representa lo que estoy transmitiendo. Git Branching Diagram


8
2017-07-15 20:37