Siguiendo git-flow, ¿cómo debería manejar una revisión de una versión anterior?

Si intenta seguir el modelo 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 necesitas hacer una revisión para 1.0. Crea una rama de revisión a partir de la etiqueta 1.0 e implementa la revisión allí. ¿Pero entonces qué?

Normalmente, se fusionaría con master y colocaría una etiqueta 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 etiqueta de lanzamiento en la rama de revisión, pero eso crearía una rama permanente al lado del maestro que contendría una etiqueta de lanzamiento. ¿Es esa la forma correcta?

Parece que hay un concepto de rama de "soporte" en git flow. 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

... haz tu solución, 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 git flowcomandos

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

... haz cambios entonces:

git flow hotfix finish 6.0.1

¡Interesante pregunta! El flujo que vinculó asume que el maestro puede rastrear la producción. Eso solo funciona si las versiones de producción aumentan estrictamente. Eso suele ser cierto para un sitio web que tiene solo una versión de producción.

Si tiene que mantener varias versiones de producción, una rama para realizar un seguimiento de la producción no es suficiente. Una solución es no utilizar master para realizar un seguimiento de la producción. En cambio, las ramas del uso como release1, release2, etc.

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

git-flow asume que solo admite una línea de lanzamiento a la vez, convenientemente rastreada por maestro. Si mantiene más de 1, deberá modificar el proceso de git-flow para tener múltiples rastreadores de sus versiones separadas que está apoyando (master-1, master-2). Puede continuar usando master 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 (master en lugar de master-2).

Desafortunadamente, cualquier herramienta de git-flow que pueda estar usando probablemente necesitará ser modificada, pero es de esperar que esté lo suficientemente familiarizado con el proceso de git-flow para manejar este caso específico directamente con los comandos de git.

git config --add gitflow.multi-hotfix true ¡Este comando parece funcionar para mí!