Nuestra línea de productos de software requiere desarrollar y mantener múltiples versiones de software al mismo tiempo. Somos novatos de Git relativos y Git Flow recientemente adoptado para aprovecharEl modelo de ramificación de Driessen.. Tenemos un equipo de software muy pequeño con pocos desarrolladores dedicados (todos usamos muchos sombreros) y ningún "gurú de la integración".

Muchas búsquedas han dado como resultado pequeños consejos específicos sobre cómo adaptar Git y Git Flow a nuestras necesidades. Lo que ha surgido es que Git Flow no está bien adaptado para admitir múltiples versiones a la vez. Unodiscusión relacionada sobre SO tiene respuestas que indican que se deben usar nombres de bifurcaciones separadas para rastrear las historias de versiones separadas. Esto, y las estrategias relacionadas, eliminan Git Flow a menos que se modifique; Vea las limitaciones de nuestro equipo arriba por una razón por la cual esto no es práctico para nosotros.

La pregunta clave es: ¿qué otros han encontrado como un buen enfoque para implementar el modelo de ramificación de Driessen lo más cerca posible al tiempo que admiten múltiples líneas de lanzamiento?

ACTUALIZACIONES:

La destilación de las respuestas a continuación (especialmente @Rasmus ') con búsquedas más específicas y discusiones internas sobre algunas opciones lleva a la siguiente solución que estamos implementando y que ofrezco como un enfoque que puede ser relevante para equipos similares en condiciones similares.

No seguiremos utilizando Git Flow. En lugar de eso, aplicaremos el modelo de Driessen a cada línea de lanzamiento individual en un repositorio precediendo el nombre de cada rama con su cadena de lanzamiento deseada, por ejemplo:

r1.5/develop

Todas las versiones de un proyecto están contenidas en el repositorio Git. Comenzar una nueva versión del proyecto consiste en crear un pequeño conjunto de nuevas sucursales de larga duración precedidas por la cadena de lanzamiento (por ejemplo,r1.6/develop y, en nuestro caso,r1.6/release; nomaster con su implicación del único buen estado acumulable actual).

Establecemos un repositorio público central por proyecto en un servidor que será la vía principal para compartir código a través del repositorio localremote campo de golf. Un impulso a este repositorio significa código que está listo para ser consumido por otros. FusionandoRX.Y/develop en y luego empujando elRX.Y/release rama significa código que está destinado a la liberación.feature, hotfix, et. Alabama. Las ramas se manejan de manera similar. El historial de combinación / confirmación de una línea de lanzamiento dada es limpio y comprensible. No queremos la típica estrategia de repo distribuida de Git para evitar la complejidad de fusionar repositorios que, con el tiempo, es probable que divergan en la estructura.

En algunas GUI de Git (como SourceTree, por ejemplo), esta estructura de rama se reconoce y se muestra como jerárquica, lo que ayuda a comprender el historial de un proyecto de nivel superior de la estructura de rama.

Disculpas por no votar ninguna respuesta; Mi reputación en SO aún no es el mínimo requerido para hacerlo.