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


Si intentas seguir el modelo de ramificación de git-flow, documentado aquí y con herramientas aquí, ¿cómo debes 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?


74
2018-05-05 15:53


origen


Respuestas:


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óncon 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 git flow comandos

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

53
2017-10-10 09:20



¡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 release1, release2, etc.

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


27
2018-05-05 16:16



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.


6
2018-05-05 16:21