Estoy tratando de elegir un flujo de trabajo de Git que sea más apropiado para nuestro producto. Aquí están los parámetros:
- Hacemos algunos lanzamientos importantes al año, digamos 10 como máximo
- Tenemos varias versiones de nuestro producto activas al mismo tiempo (algunas personas están en v10.1, otras en v11.2, etc.)
- Necesitamos poder trabajar en varias versiones al mismo tiempo (por lo que podríamos estar trabajando en v12.1, pero a medida que llegamos al final de la versión, comenzamos a trabajar en v12.2 al mismo tiempo)
- Necesitamos poder corregir las versiones cuando se encuentran errores críticos
Hasta ahora, esta es la forma en que creo que podría funcionar:
- Se utiliza un repositorio remoto único
- Crear rama 12.1 desde maestro
- Cree ramas de características basadas en 12.1, comprométalas y vuelva a combinarlas en 12.1, presione
- Una vez que necesitemos comenzar a trabajar en futuras versiones, cree una nueva sucursal 12.2 basada en 12.1
- A partir de ese momento, cuando trabaje en una característica para 12.1, cree una ramificación a partir de 12.1, confirme los cambios y combínelos en 12.1 y 12.2, presione
- Si trabaja en una función para 12.2, cree una rama desde 12.2, confirme cambios y combine solo en 12.2, presione
- Cuando se complete la versión 12.1, combínelo en maestro y etiquete la rama maestra con 12.1
- Si se necesita un hotfix, cree una rama de hotfix a partir de la rama de versión más antigua que lo necesite, confirme los cambios y vuelva a fusionarla en todas las ramas de versión para esa versión y versiones futuras que puedan verse afectadas; Si la última rama de la versión estable se vio afectada, combínela en maestra.
Tengo algunas preocupaciones:
- No estoy seguro de que la fusión de las revisiones de las ramas viejas en las ramas nuevas sea un proceso sencillo, especialmente si ha habido muchos cambios superpuestos; ¿Sería más inteligente simplemente revisar manualmente en cada rama en los casos en que parece que habrá conflictos?
- Los modelos de flujo de trabajo que he visto parecen no mantener vivas las ramas de lanzamiento mucho, una vez hecho, el lanzamiento se fusiona en maestro, etiquetado y eliminado. Mi problema con eso es que no tengo una buena idea de cómo administrar el estado de la versión si todo lo que tengo son etiquetas en master, parece más fácil de corregir en una rama y luego tengo una versión a la que siempre puedo volver que tiene la última revisión (incluso puedo etiquetar las revisiones en el lanzamiento). No estoy seguro de que haya una manera de volver al master y de alguna manera tener una copia del lanzamiento con las revisiones aplicadas y actualizar esa etiqueta.
Se agradecen los comentarios sobre cosas que podría haber pasado por alto o mejores formas de lograr cosas dados los requisitos que he especificado.
version-control
git
Cohete04
fuente
fuente
Respuestas:
Parece que se está ramificando en cada versión principal (12.0.0), luego tiene posibles actualizaciones menores para cada una (12.1.0) y correcciones urgentes (12.2.1). ¿Correcto?
No hay una razón específica por la que no pueda mantener vivas las ramas de liberación en GitFlow después de la publicación de una liberación, aparte del hecho de que coordinar los cambios entre varias ramas divergentes durante mucho tiempo es difícil con cualquier modelo. Supongo que GitFlow también se modeló más para productos que mantienen un solo lanzamiento en vivo mientras se desarrolla el siguiente.
Me quedaría con GitFlow y haría algunas enmiendas;
Salta la rama maestra. No he tenido un uso práctico hasta ahora, y perdería su linealidad en la forma en que trabaja. Mantenga el desarrollo en la próxima versión principal de desarrollo. Si decide mantener el maestro, no coloque etiquetas de lanzamiento en el maestro, póngalos en la última confirmación en la rama de lanzamiento que produjo el binario que está enviando.
No deseche las ramas de liberación después de fusionarlas para desarrollarlas. En su lugar, manténgalos disponibles para la próxima versión menor y las posibles soluciones rápidas. Si alguna vez deja de admitir una versión, supongo que está bien eliminarlos. Puede nombrar ramas de lanzamiento después de su componente principal, lanzamiento / 12, y luego crear ramas de lanzamiento secundario, lanzamiento / 12.1, lanzamiento / 12.2 fuera de él. No he tenido que preocuparme demasiado por este nivel de paralelismo, pero eso es probablemente lo que intentaría. Puede pensar en cada rama de lanzamiento principal como su propio entorno sub-GitFlow en este caso.
Si debe trabajar en paralelo en funciones para varias versiones principales futuras al mismo tiempo, tal vez deba mantener la siguiente (13) en desarrollo y cualquier cosa para versiones posteriores (14, 15) en ramas adicionales de "desarrollo-N" . Eso parece muy difícil de mantener en general, pero sería posible.
fuente
Parece que una posible solución para su problema principal ( «Necesitamos poder trabajar en varias versiones al mismo tiempo [...]» ) está haciendo un
git worktree add <path> [<branch>]Consulte esta respuesta SO para obtener una introducción detallada sobre
git worktree.fuente
Mencionaste que estás familiarizado con gitflow. Sugiero adaptarlo para su escenario. Deberá crear ramas desde su rama de desarrollo para admitir versiones anteriores. Estas versiones anteriores también necesitarán tener sus propias ramas de lanzamiento / master y ramas de revisión. Deberá fusionar periódicamente sus ramas de soporte en las ramas de soporte más nuevas y la rama de desarrollo.
A medida que el desarrollo de las versiones principales diverge, esto se volverá cada vez más difícil. No hay una bala de plata para esto. A veces será más fácil hacer cambios manualmente. El costo de mantener las versiones anteriores aumentará, y en algún momento ya no valdrá la pena.
Todo depende de qué tipo de cambios esté haciendo en sus versiones anteriores. Si solo se solucionan errores, es relativamente fácil de combinar. Si intentas agregar nuevas funciones, será difícil.
fuente