Evitar la rejilla de Doom ™ en Git-Flow


8

Mi proyecto sigue el modelo de ramificación de Git Flow . El desarrollo ocurre develop, que se fusiona mastery etiqueta allí para los lanzamientos. Las revisiones se realizan en ramas ramificadas de la actual master.

Sin embargo, el desarrollo actual también necesita las revisiones, por lo que también se fusiona cada rama de revisión develop.

Esto crea gráficos de revisión muy feos, especialmente los desarrollos / revisiones que se combinan a menudo en un corto período de tiempo:

Gráfico de revisión feo

¿Es este un problema que la gente suele tener con Git-Flow, y hay una solución fácil para ello?


2
¿Con qué frecuencia está lanzando una nueva versión y está utilizando ramas de revisión solo para las correcciones que no pueden esperar hasta la próxima versión programada?
Bart van Ingen Schenau

@BartvanIngenSchenau puede ser varias veces al día, pero generalmente cada dos días. El hotfix se ramifica solo para arreglos que no pueden esperar, sí.
Hannes Struß

44
¿Por qué la estética de un gráfico de revisión es un problema?

1
¿ El tipo de rebase no resuelve este problema?
Cuthbert

1
@Cuthbert hasta cierto punto, pero no puede volver a crear el master en desarrollo sin forzar, lo cual no es una opción.
Hannes Struß

Respuestas:


2

¿Entonces su problema es que está fusionando cada solución dos o tres veces? (Primero para dominar, luego para desarrollar, finalmente para desarrollar de nuevo para dominar)

¡Si eso es! Sin embargo, no puedo evitar eso, las revisiones deben fusionarse en desarrollo

Claro, pero ¿por qué fusionarse de desarrollar a maestro si nada realmente cambió?

Eche un vistazo a una de esas master<-develop<-hotfixfusiones: no debería haber ningún cambio real allí (después de todo, la revisión ya se fusionó directamente con la maestra). Si no hay cambio, simplemente no lo hagas.

En cualquier caso, de acuerdo con su documento vinculado, las únicas fusiones de desarrollo a maestro deberían ir a través de una rama de lanzamiento. En cambio, está manteniendo el maestro sincronizado con su rama de desarrollo (inestable), no lo haga.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.