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

gitflow merge

Question

Nuestra línea de productos de software requiere desarrollar y mantener múltiples versiones de software al mismo tiempo. Somos relativamente novatos en Git y recientemente adoptamos Git Flow para aprovechar el modelo 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 tiempo. Una discusión relacionada sobre SO tiene respuestas que indican que se deben usar nombres de ramas diferentes para rastrear 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 que es un buen enfoque para implementar el modelo de ramificación de Driessen lo más fielmente posible al tiempo 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 modelo de Driessen a cada línea de liberación individual en un repositorio introduciendo cada nombre de rama con su cadena de lanzamiento prevista, por ejemplo:

r1.5/develop

Todas las versiones de un proyecto están contenidas en el repositorio de Git. Iniciar una nueva versión del proyecto consiste en crear un pequeño conjunto de nuevas ramas 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 corriente) buen estado edificable).

Establecemos un repositorio público central por proyecto en un servidor que será la avenida principal para compartir el código a través de los enlaces remote repositorio local. Un impulso a este repositorio significa código que está listo para ser consumido por otros. RX.Y/develop y luego presionar la rama de RX.Y/release significa código destinado a la publicación. feature , hotfix , et. Alabama. las ramas 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 repositorios distribuidos de Git a favor de evitar la complejidad de fusionar los repos que, con el tiempo, 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.

Answer 1

Nuestro proceso de desarrollo habitual se adapta bien al flujo de trabajo de Driessen, pero a veces necesitamos desarrollar una rama con varias características para una versión especializada, en la que no queremos incluir 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 rama 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 etiqueta allí por conveniencia (inicio-22.4.2)
3. Comience cada nueva característica 22.4.2 con start-22.4.2 (un conjunto de cambios en desarrollo) ya que es padre / base . Esto evita que cualquier trabajo fusionado para desarrollar mientras tanto se filtre en la rama de lanzamiento. Tanto la línea de comandos como Sourcetree admiten elegir un padre además del consejo para el git flow feature start .
4. Combine manualmente desde la punta de la rama 22.4.2 a la función, 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 rama.
5. git flow feature finish la función, 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 menos probado).
6. Después de finish , fusionamos manualmente el último conjunto de cambios antes del cierre de la función en la rama 22.4.2.

Answer 2

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

Answer 3

estamos teniendo una configuración 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 referencia inicial como refs / heads / platformX.Y / luego construimos sobre eso

De modo que, dependiendo de lo que necesite hacer, ejecute platformX.Y / develop y empiece a trabajar desde ese punto en una rama de funciones y se fusionará para desarrollarse cuando haya terminado.

Esto funciona para nosotros y podemos seguir el modelo nvie.

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