En caso de que las ramas de liberación se fusionen para dominar

Mi equipo está utilizando el modelo de ramificación Git Stable Mainline y estamos a punto de crear la primera rama de lanzamiento. Por lo que he leído hasta ahora, parece que las ramas de liberación están aisladas de la rama maestra y nunca se fusionaron por completo con la maestra. En cambio, si se realiza una corrección en la rama de lanzamiento, generalmente se vuelve a seleccionar la rama maestra. Esto tiene sentido para mí, ya que desearía mantener la versión actual completamente separada del desarrollo de la próxima versión, al mismo tiempo que puede desarrollar el próximo conjunto de características en master al mismo tiempo que prepara la versión actual.

¿Durante cuánto tiempo deben mantenerse estas ramas de liberación? ¿Hay algún caso en el que deberían volver a fusionarse completamente en master?

git release-management

La estrategia de ramificación que use depende completamente del flujo de trabajo de su organización y de los requisitos específicos.

— Robert Harvey

How long should these release branches be kept around for?Siempre que espere recibir un mensaje de error para esa versión que desea reproducir desde el código fuente. No eliminaría ninguna rama de lanzamiento porque una rama tiene una pequeña huella de kilobytes en el servidor. solo el delta cuesta memoria de disco duro

— k3b

cherry pickingtodos y cada uno de los commits en la rama de lanzamiento en master o merging release en master es técnicamente la misma cosa que no "ver" cherry picksen el historial de git. Por lo tanto, preferiría que mergingcada corrección vuelva al maestro usando la --no-ffopción gits para que el historial muestre la rama de lanzamiento adicional.

— Timothy Truckle

Qué quiere decir esto: bitsnbites.eu/a-stable-mainline-branching-model-for-git que explícitamente dice que nunca para fusionar las ramas de liberación hacia atrás

— Ewan

Gracias a todos por la retroalimentación. @Ewan Sí, pero también leí algo de documentación general de Git escrita por Microsoft y parecía que nunca fusionaron toda la rama de lanzamiento a master tampoco.

¿Por cuánto tiempo deben mantenerse estas ramas?

La primera respuesta que aparece en mi mente aquí es:

¿Por qué estás creando una rama de lanzamiento en primer lugar?

Si tiene la intención de poder brindar soporte a una versión en uso de producción, entonces debería vivir tanto como esa versión viva con sus clientes. (por ejemplo, soporte LTS, podría tener múltiples ramas de este tipo, haciendo las cosas un poco más complejas)

Si está separando el trabajo de estabilización del nuevo desarrollo en curso, una vez que se implemente la versión, ya no necesitará esa rama. Aquí esto indicaría una tubería de entrega continua. Cualquier error se soluciona en la próxima versión, que ocurriría con la mayor frecuencia posible. Algunos empujan esto a considerar la rama maestra como la rama estable que se implementa varias veces al día. Otros se sincronizarán con sus sprints y lanzarán cada dos o tres semanas.

¿Deberías fusionarlo completamente con el maestro?

Como supones, todo depende de por qué adoptaste esta estrategia de ramificación. para un estilo de entrega continuo, ya que la rama nunca se volverá a usar, entonces debe tratarla como lo haría con cualquier característica o ramas de corrección de errores, es probable que la fusione nuevamente con el maestro y se olvide de ella.

Sin embargo, si apunta al estilo LTS, es probable que no lo fusione de nuevo, especialmente si tiene múltiples ramas de este tipo. Aquí aplicaría la corrección a todas las ramas de lanzamiento y la selección de cereza de una de ellas para fusionar esa corrección en el maestro. En este escenario, lo último que querría hacer es tratarlo como cualquier otra rama de características en la que los cambios del maestro se incorporan y los conflictos se resuelven allí en lugar de hacerlo en el maestro.

Sin saber más sobre el ciclo de vida de su producto y el flujo de trabajo de su equipo, es difícil encontrar un consejo más preciso aquí.

— Newtopian
fuente

Esto implica que la rama se pierde después de la fusión, lo cual no es un caso. La rama de lanzamiento también debe fusionarse en el maestro en modo LTS. No hay razón para no fusionar las ramas de liberación.

— Basilevs

No se trata de perder las ramas, sino más bien de obligar a uno a pensar, fusionar sistemáticamente las ramas LTS las haría fusionar duplicados para cada rama LTS que esté activa. Una corrección de errores solo necesita fusionarse de nuevo una vez a la principal y probablemente no desde una rama LTS, ya que la versión más reciente probablemente aún no esté en LTS y esté más cerca del estado de la rama maestra. En este escenario, uno elegiría desde la versión más reciente, la rama LTS casi nunca sería empujada al maestro. Que la rama se pierda o no después de una fusión es irrelevante.

— Newtopian

¿Por qué preferiríamos duplicar selecciones de cereza inseguras para duplicar con seguridad la fusión? Por "seguro" me refiero al seguimiento y propagación de cambios protegidos criptográficamente.

— Basilevs

Un enfoque similar funciona sin selecciones de cereza aplicando la corrección a la rama más antigua y fusionando la más antigua con la más nueva. Si se pueden evitar las selecciones de cereza, ¿por qué usarlas? Parece que no entiendo algo en el modelo estable Mainline ...

— Basilevs