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


101

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?


posible duplicado de Git-flow y master con múltiples ramas de liberación paralelas [aunque la otra pregunta es más nueva, tiene respuestas más útiles, así que he marcado esta pregunta como duplicada]
danio

Respuestas:


74

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

? mantener estas ramas de soporte o eliminarlas después de un período
Evan Hu

@EvanHu bueno, seguro guárdalos siempre que tengas esa sucursal en producción en algún lugar. Después de eso, es una cuestión de registro histórico. Es posible que desee saber cómo se corrigieron las revisiones si alguna vez volvieran a ocurrir.
Klas Mellbourn

Uno debería hacer un lanzamiento en el hotfix, ¿verdad? ¿Cómo podemos hacer eso?
Ravindranath Akila

33

¡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.


Puede cambiar git-flow para configurar las etiquetas de lanzamiento en las ramas de lanzamiento. Ese es un cambio bastante importante. Rompería los guiones actuales. Además, ¿qué contendría entonces el maestro?
Klas Mellbourn

3
Las git-flowherramientas no son adecuadas si tiene que admitir varias versiones de producción. En el flujo de trabajo propuesto en esta respuesta, master no se usa en absoluto. Podría nombrar el maestro de la rama de desarrollo, después de todo, es solo un nombre.
Andomar

GitFlow admite el seguimiento de más de una versión de producción: gitversion.readthedocs.io/en/latest/git-branching-strategies/…
Andre L

7

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.


Si modificas el git flowproceso, será algo diferente. Si algún modelo debe ser reparado (no solo extendido), entonces es tan exitoso como afirma su autor. Consulte mi respuesta al tema que estamos discutiendo.
Victor Yarema

0

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

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.