Después de git-flow, ¿cómo manejarías una revisión de una versión anterior?

Si intenta seguir el model de ramificación de git-flow, documentado aquí y con herramientas aquí , ¿cómo debe manejar esta situación?

Ha realizado una versión 1.0 y una versión 2.0. Entonces necesita hacer una revisión para 1.0. Crea una twig de revisión de la label 1.0 e implementa la solución allí. ¿Pero entonces qué?

Normalmente se fusionaría para dominar y colocaría una label de lanzamiento 1.1 allí. Pero no puede fusionar 1.1 a un punto después de 2.0 en el maestro.

Supongo que podría poner la label de lanzamiento en la twig de la revisión, pero eso crearía una twig permanente al lado del maestro que contendría una label de lanzamiento. ¿Es ese el path correcto?

Parece que hay un concepto de una twig de "soporte" en el flujo de git. Esto se usa para agregar una revisión a una versión anterior.

Este hilo tiene más información , con estos ejemplos:

git checkout 6.0 git checkout -b support/6.x git checkout -b hotfix/6.0.1 

… arregla tu problema, entonces:

 git checkout support/6.x git merge hotfix/6.0.1 git branch -d hotfix/6.0.1 git tag 6.0.1 

o usando commands de git flow

 git flow support start 6.x 6.0 git flow hotfix start 6.0.1 support/6.x 

… haga cambios entonces:

 git flow hotfix finish 6.0.1 

¡Interesante pregunta! El flujo que vinculó supone que el maestro puede rastrear la producción. Eso solo funciona si las versiones de producción son estrictamente crecientes. Eso es típico para un website que solo tiene una versión de producción.

Si tiene que mantener múltiples versiones de producción, una twig para rastrear la producción no es suficiente. Una solución es no usar maestro para seguir la producción. En su lugar, use twigs como release2 , release2 , etc.

En este enfoque, es posible que ni siquiera necesite una twig de revisión. Podría solucionar el problema en la twig release1 . Cuando la solución sea lo suficientemente buena, cree una label release1.1 en la twig release1 .

git-flow asume que solo está soportando una línea de liberación a la vez, convenientemente rastreado por el maestro. Si mantiene más de 1, necesitará modificar el process de flujo de git para tener múltiples rastreadores de sus versiones por separado que está soportando (maestro-1, maestro-2). Puede seguir utilizando maestro para rastrear la línea de lanzamiento más reciente, además o en lugar de un rastreador específico para la línea de lanzamiento más reciente (maestro en lugar de maestro-2).

Desafortunadamente, cualquier herramienta de gitflow que pueda estar usando probablemente necesite modificarse, pero con suerte estará lo suficientemente familiarizado con el process de gitflow para manejar este caso específico directamente con los commands de git.