start - Después de git-flow, ¿cómo manejarías una revisión de una versión anterior?
git flow release example (3)
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 necesita hacer una revisión para 1.0. Crea una rama de revisión de la etiqueta 1.0 e implementa la solución allí. ¿Pero entonces qué?
Normalmente se fusionaría para dominar 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 liberación en la rama de revisión, pero eso crearía una rama permanente al lado del maestro que contendría una etiqueta de liberación. ¿Es ese el camino correcto?
¡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 sitio web que solo tiene una versión de producción.
Si tiene que mantener múltiples versiones de producción, una rama para rastrear la producción no es suficiente. Una solución es no usar maestro para seguir la producción. En su lugar, use ramas como release2 , release2 , etc.
En este enfoque, es posible que ni siquiera necesite una rama de revisión. Podría solucionar el problema en la rama release1 . Cuando la solución sea lo suficientemente buena, cree una etiqueta release1.1 en la rama release1 .
Parece que hay un concepto de una rama 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 comandos 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
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 proceso 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 proceso de gitflow para manejar este caso específico directamente con los comandos de git.