¿Cómo se puede usar git-flow de manera efectiva en un proyecto en el que se mantiene más de una versión principal?

He migrado varios de mis proyectos al flujo de trabajo de git flow, y me encanta. Sin embargo, no he encontrado una mejor práctica que haga que las cosas fluyan sin problemas al trabajar con un proyecto en el que se mantiene más de una versión principal a la vez.

Específicamente, no estoy manteniendo una "versión gratuita" y una "versión paga" o cualquier otro modelo paralelo, estoy hablando de un proyecto en el que se lanza la Versión 1, y sigue siendo compatible con versiones menores (1.1, 1.2, etc. .) hasta que se haya lanzado la Versión 3, momento en el que se mantendrían los puntos 2 y 3, hasta que se lance 4 ... entiendes la idea.

¿Cómo ha mantenido o mantendría dos o más versiones compatibles de un proyecto a la vez en un flujo de trabajo de gitflow?

git workflows gitflow

— HedgeMage
fuente

No tengo ningún atm de ejemplos, pero los proyectos que conozco utilizan repositorios separados para diferentes versiones principales y parches de backport de uno a otro.

— ProdigySim

@ProdigySim: Gracias por el punto de datos, pero ¿soy solo yo o eso agregaría una cierta cantidad de sobrecarga para rastrear y administrar?

— HedgeMage

@ProdigySim Sospecho que esos proyectos no utilizaron una herramienta con las capacidades de ramificación y fusión de git.

— Rein Henrichs

@Rein Utilizan Mercurial. No creo que la ramificación sea muy limpia en términos de seguimiento de versiones principales paralelas de software.

— ProdigySim

Entonces mi sospecha fue correcta. Y sí, está bastante limpio si su herramienta lo admite correctamente. git y el kernel de Linux lo hacen de esta manera.

— Rein Henrichs

Respuestas:

man gitworkflows, el abuelo del flujo de trabajo 'git flow', describe las pautas generales del flujo de trabajo git; el uso de pu, next, mastery maintramas; y como maintse gestiona. Si tiene varias ramas de mantenimiento, se puede nombrar, por ejemplo, maint/1.x, maint/2.xy así sucesivamente.

La clave no es tanto cómo usar los comandos git, sino cómo construir un proceso razonable. Decida qué cosas son importantes para usted (¿facilidad para hacer backporting?) Y cree (y documente) un flujo de trabajo que satisfaga esas limitaciones.

— Rein Henrichs
fuente

¿Pero esto responde la pregunta? A saber, ¿soporta git-flow un modelo de lanzamiento flexible como se describe en la pregunta, o uno vuelve a los comandos básicos de git? ("gitworkflows" describe el uso básico del flujo de trabajo de git, pre-git-flow). Git-flow fue creado (aparentemente) para simplificar los procesos de fusión / ramificación de git, de modo que los equipos (con diversos grados de destreza de git-fu) pudieran centrarse en la codificación y evite los errores de "fusión errónea" que llevan mucho tiempo. ¿Es posible con git-flow mantener y desarrollar v1.2. {1,2,3, ..} al mismo tiempo que v2.5. {1,2,3, ...}? ¿Quizás con ramas de lanzamiento a largo plazo? O master1, master2, ...?

— michael

Básicamente, duplicaría el master, releasey las developramas para cada versión principal que esté manteniendo. La forma en que interactúan entre sí sigue siendo la misma. Por featureramas, sólo asegúrese de que la rama de la rama más antigua que la intención de fusionar la espalda en , lo que impide tirando en las dependencias no deseadas. Luego, cuando vuelvas a fusionar tu featurerama, solo haces fusiones adicionales en cada rama más nueva y apropiada de la versión principal.

— Karl Bielefeldt
fuente

¿No es el punto principal del maestro incluir todas las versiones lanzadas?

— HedgeMage

@HedgeMage, en un ciclo de lanzamiento más lineal, ese es el caso, pero eso es muy poco práctico para las versiones principales paralelas.

— Karl Bielefeldt

Esta parece ser la solución más práctica, a menos que exista algún truco probado que utilice hotfixes o algo que no conozco. He estado buscando una forma de introducir git-flow y aún ser capaz (como requisito previo desafortunado) de mantener nuestro modelo de versión existente, donde tenemos que mantener / desarrollar versiones anteriores (no solo revisiones). Entonces v5.1.x se mantendrá (con nuevas características agregadas, errores corregidos, etc.) un par de años después del lanzamiento de v6.1.x. Aproximadamente 2-3 versiones principales compatibles y desarrolladas en un momento dado. Pero las correcciones de errores deben aplicarse a cada versión donde existe el error.

— michael