sheet - git-flow windows
Múltiples ramas de desarrollo con git-flow. (4)
Actualmente estoy buscando mucho en git-flow, y tratando de averiguar cómo usarlo para los proyectos en los que estoy involucrado.
He visto los diversos tutoriales de git-flow y estoy bastante familiarizado con git. Por lo tanto, no necesito ningún consejo sobre git solo, sino directamente en el flujo de trabajo con git-flow.
Aquí está la situación:
Cuando comparto una versión (llamémosla 1.0), esta secuencia se desarrolla, lo cual está bien. Digamos que ahora comienzo a trabajar en 2.0, agregando nuevas características. Y, por supuesto, quiero fusionarlos de nuevo en desarrollo, una vez que haya terminado. Ahora el hotfixing en 1.0 está bien, así que digamos que produzco varias versiones 1.0.1, 1.0.2, etc. Todo esto también actualizará la rama de desarrollo, lo cual también es bueno. Hasta ahora, sin problemas, puedo desarrollar funciones para 2.0 y revisiones para 1.0.x de forma independiente.
Sin embargo, digamos que alguien solicita una nueva característica para una versión 1.1. Ahora tengo un problema. Si creo una rama de características, esto se basará en la rama de desarrollo, que puede que ya contenga 2.0, lo que no deseo en esta versión 1.1.
¿Hay una manera simple, para manejar estos cambios 2.0 y 1.1 de forma independiente?
Hay varias posibilidades que ya veo:
crear una nueva rama en la última posición de lanzamiento en desarrollar. Cambie el desarrollo a esta posición y cambie el nombre de la otra rama de desarrollo. Sin embargo, esta rama no contendría ningún hotfix de 1.0.1 etc.
No fusione las características de 2.0 antes de que se haga 2.0. Sin embargo, entonces tendría que dejar muchos cambios abiertos hasta el último momento. Además, esto no ayuda, si 2.0 se publican y luego se solicitan cambios a 1.0.x.
¿Es esto posible con git flow? ¿Es decir, basar los lanzamientos en un lanzamiento anterior una vez que el trabajo para un lanzamiento más nuevo se ha iniciado o incluso terminado?
¿Es esto posible con git flow?
Cualquier cosa es posible utilizando git-flow como una serie de mejores prácticas en lugar de una regla difícil. Simplemente abra sus ramas de características desde su versión 1.0 lugar de desde su rama de develop .
Creo que si quieres admitir dos versiones de la aplicación al mismo tiempo, será mejor crear dos repositorios diferentes para eso.
Más sobre "git-flow mejorado":
https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
La clave es iniciar las características desde el punto de la última versión. Si tiene 1 o más versiones compatibles publicadas no debería ser un problema.
ACTUALIZAR:
Lo tengo reescrito - en forma de blog:
Me doy cuenta de que esta es una pregunta antigua, pero acabo de encontrar una manera bastante simple de manejarlo por mi parte.
En mi servidor de desarrollo básicamente tengo dos copias de trabajo, una para v1.0 y otra para v2.0.
Luego creo una rama de "desarrollo" separada para v2.0, y cuando ejecuto "git flow init" en el entorno 2.0, uso esta como mi rama de "próxima versión".
Estoy seguro de que podrías hacer lo mismo con la rama maestra, pero para mis propósitos esto fue suficiente.