Asesoramiento sobre múltiples líneas de liberación y git-flow, para git no gurús

Nuestra línea de productos de software requiere desarrollar y mantener múltiples versiones de software al mismo time. Somos relativamente novatos en Git y recientemente adoptamos Git Flow para aprovechar el model de ramificación de Driessen . Tenemos un equipo de software muy pequeño con pocos desarrolladores dedicados (todos llevamos muchos sombreros) y ningún "gurú de la integración".

Mucha búsqueda ha revelado pequeños consejos específicos sobre cómo adaptar Git y Git Flow a nuestras necesidades. Lo que ha aparecido es que Git Flow no es adecuado para admitir múltiples versiones al mismo time. Una discusión relacionada sobre SO tiene respuestas que indican que se deben usar nombres de twigs diferentes para rastrear historias de versiones separadas. Esto, y las estrategias relacionadas, eliminan Git Flow a less 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 key es: ¿qué otros han encontrado que es un buen enfoque para implementar el model de ramificación de Driessen lo más fielmente posible al time que es compatible con múltiples líneas de lanzamiento?

ACTUALIZACIONES:

Destilar las respuestas a continuación (particularmente @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 bajo condiciones similares.

No continuaremos usando Git Flow. En su lugar, aplicaremos el model de Driessen a cada línea de liberación individual en un repository introduciendo cada nombre de twig con su cadena de lanzamiento prevista, por ejemplo:

r1.5/develop 

Todas las versiones de un proyecto están contenidas en el repository de Git. Iniciar una nueva versión del proyecto consiste en crear un pequeño set de nuevas twigs de larga vida precedidas por la cadena de publicación (por ejemplo, r1.6/develop y, en nuestro caso, r1.6/release ; no master con su implicación de la única stream) buen estado edificable).

Establecemos un repository público central por proyecto en un server que será la avenida principal para compartir el código a través de los enlaces remote repository local. Un impulso a este repository significa código que está listo para ser consumido por otros. RX.Y/develop y luego presionar la twig de RX.Y/release significa código destinado a la publicación. feature , hotfix , et. Alabama. las twigs se manejan de manera similar. El historial de fusión / confirmación de sucursal para una línea de lanzamiento dada es limpio y comprensible. No queremos la típica estrategia de repositorys distribuidos de Git a favor de evitar la complejidad de fusionar los repos que, con el time, puedan diferir en la estructura.

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

Disculpas por no votar ninguna respuesta; mi reputación en SO aún no es la mínima requerida para hacerlo.

estamos teniendo una configuration similar, excepto que tenemos más de 300 desarrolladores dedicados, tenemos exactamente lo que usted describió, varias revisiones que necesitamos entregar a diferentes clientes.

Lo hemos dividido, así que tenemos una reference inicial como refs / heads / platformX.Y / luego construimos sobre eso

De modo que, dependiendo de lo que necesite hacer, ejecute platformX.Y / develop y comience a trabajar desde ese punto en una twig de características y se fusionará para desarrollarse cuando haya terminado.

Esto funciona para nosotros y podemos seguir el model nvie.

Además de todo, estamos fusionando todas estas sucursales en la twig X.Y con nuestra twig principal de desarrollo, de modo que los errores corregidos en esas twigs también se lanzan al último software.

Nuestro process de desarrollo habitual se adapta bien al flujo de trabajo de Driessen, pero a veces necesitamos desarrollar una twig con varias características para una versión especializada, en la que no queremos include la mayor parte del desarrollo continuo. Hemos encontrado una forma de hacer esto dentro del flujo utilizando las herramientas existentes, con solo un par de pasos adicionales. (Estamos trabajando en mercurial, pero las opciones para git flow y hg flow son las mismas).

Por ejemplo, nuestra próxima versión normal es 23.0, y nuestra versión especial, "sandboxed" es 22.4.2. Para estos casos, nosotros:

  1. Desde el principio, antes de que se creen las nuevas funciones, cree una twig de publicación 22.4.2 para la versión especial de desarrollo. Está bien si algunas características se iniciaron antes, siempre y cuando no aparezcan después de ningún trabajo de desarrollo que deseemos excluir.
  2. Haga una label allí por conveniencia (inicio-22.4.2)
  3. Comience cada nueva característica 22.4.2 con start-22.4.2 (un set de cambios en desarrollo) ya que es padre / base . Esto evita que cualquier trabajo fusionado para desarrollar mientras tanto se filtre en la twig de lanzamiento. Tanto la command-line como Sourcetree admiten elegir un padre además del consejo para el git flow feature start .
  4. Combine manualmente desde la punta de la twig 22.4.2 a la function, si lo desea, y con la frecuencia que desee, para incorporar las funciones completadas de la sucursal. Esto nos permite tratar cualquier interacción de preocupación entre las nuevas características 22.4.2 en la twig.
  5. git flow feature finish la function, que la fusiona para desarrollarse de forma normal. (Para nosotros, estas funciones están destinadas a ser incluidas en futuras versiones. Solo protegemos 22.4.2 del trabajo less probado).
  6. Después de finish , fusionamos manualmente el último set de cambios antes del cierre de la function en la twig 22.4.2.

Una solución es cambiar la variable de configuration gitflow.branch.develop . Usted crea una branche en su versión lanzada y usa esa twig como su nueva twig de desarrollo. A partir de ahí, utiliza los commands habituales de git-flow. Si desea fusionar automáticamente esa tarea en la twig de desarrollo original, cambie la variable gitflow.branch.develop antes del command de finalización de git-flow.