Git workflows / gitflow: múltiples proyectos simultáneos grandes

Estoy tratando de averiguar si podría utilizar un flujo de trabajo Gitflow modificado de Git, y estoy luchando con él (no estoy seguro de si es relevante, pero si planeo usar Atlassian Stash):

Actualmente usamos CVS y tenemos múltiples proyectos en marcha a gran escala. Hacemos nuevos lanzamientos de producción de proyectos cada mes más o less, pero cada proyecto podría estar en desarrollo entre 1 semana y 6 meses. También hacemos lanzamientos de mantenimiento semanales. Puede haber hasta una docena de proyectos en desarrollo activo. También necesitamos la capacidad de realizar testings de regresión todas las noches en cada twig del proyecto, así como el mantenimiento. Dada la naturaleza por file de CVS, dividimos fusiones manuales entre media docena de desarrolladores cuando se necesitan fusiones a gran escala.

Hasta ahora, mi mejor idea es usar gitflow modificado donde tendremos las siguientes twigs:

maestro: lo que está actualmente en producción

desarrollar: twig de desarrollo para la próxima versión de producción, las twigs del proyecto que se lanzarán con la próxima versión se fusionarán aquí, así como las pequeñas características que no se lanzarán a proyectos más grandes (tanto nuevas características como errores de corrección de producción)

project / project_name: twigs de desarrollo / integración / testing del proyecto. Esto se bifurca del desarrollo y se fusiona para desarrollarse cuando se completa el desarrollo del proyecto. Algunas twigs de proyecto / nombre_del_proyecto pueden ramificarse de las twigs de proyecto / nombre_proyecto existentes si requieren la funcionalidad de un proyecto en desarrollo.

feature / ticket_no: feature branch, bifurcada de develop para funciones más pequeñas que no son de proyecto. Ramificado de project / project_name para proyectos más grandes.

release / release_number: release branches, se bifurca de la twig de desarrollo a medida que decidimos que es hora de cortar el lanzamiento. Fusionado para dominar.

bugfix / ticket_no: twigs de corrección de errores, derivadas de las twigs de release / release_number para los errores encontrados por QA. Se fusionó con release / release_number y se desarrolló.

hostix / ticket_no: revisión para problemas urgentes de producción. ramificado fuera de maestro. Fusionado en twigs maestras, desarrollo y liberación.

¿Funciona esto, o me estoy disparando aquí en el pie debido a la gran complejidad de fusión que popupá? ¿Alguna sugerencia para un enfoque alternativo?

Liberar más a menudo no es una posibilidad de tener una capacidad limitada para get el time de inactividad aprobado para un lanzamiento.

El flujo de trabajo que describió es muy similar a lo que he visto en las dos últimas tiendas donde he trabajado. Lo mejor de Git es que no cuesta mucho crear una nueva sucursal. Así que, si bien puede haber una penalización considerable por crear tantas sucursales en CVS, en Git podrá crear todo su flujo de trabajo en cuestión de minutos.

Usted mencionó a Atlassian Stash, y merece mencionar que esto se refiere al repository que planea usar. El repository es la location (generalmente remota) donde su equipo almacenará las confirmaciones de todas las sucursales. Git es Git, ya sea que uses GitHub, Stash, BitBucket o cualquier otro repository, por lo que la funcionalidad que tienes no cambiará en function del repository. Sin embargo, el repository generalmente agrega herramientas para facilitar la administración de las sucursales remotas. Como repos de nivel empresarial, Stash se destaca en este sentido y debería poder manejar sus casos de uso.

Habiendo dicho eso, no necesariamente tendrás less conflictos de combinación cuando uses Git. Y no es típico tener múltiples desarrolladores resolviendo un solo conflicto de fusión en Git.

Y como una nota al margen, Git no maneja los files binarys muy bien de la caja. Entonces, si su repository de CVS actual está cargado de binarys, entonces querrá revisar todas las herramientas de control de versiones antes de adoptar Git.