Usando git flow con el subtree de git

Acabo de migrar un gran svn repo a git y comencé a usar gitflow. Funcionó como un encanto, pero ahora estoy pensando en dividir ese gran repository en varios más pequeños.

Supongamos que el tree del directory repo es el siguiente:

/repo - libs - apps -- app 1 -- app 2 

Y queremos dividirlo en tres repositorys, uno con la estructura central (libs y directorys de aplicaciones) y los otros dos con los directorys de aplicaciones.

Si utilizo el subtree git para dividir de esa manera, ¿podré usar git flow individualmente en cada parte o tendré que usarlo globalmente?

PD: Esta es mi primera pregunta en stackoverflow, por favor sé amable 🙂

No uso git flow, pero yo diría que la respuesta depende de qué tan modular sea. ¿Puede implementar la estructura principal sin implementar app1 y app2? ¿Puedes implementar app1 y app2 de forma independiente el uno del otro? ¿Su equipo de desarrollo es lo suficientemente grande y sofisticado como para tratarlos como flujos de trabajo independientes?

Si la respuesta a estas preguntas es "sí", discutiría tratarlas como proyectos múltiples, cada uno con un flujo único. Si la respuesta a cualquiera de ellos es "No", evitaría la fractura de su proyecto. De hecho, si los cambios a app1 y app2 también demandan cambios en el repository central la mayor parte del time, evitaría fracturar tus repos.

Los repositorys nesteds, ya sean ejecutados con subtree, submodules o (deidad prohibida) solo .gitignore por definición, hacen que los flujos de trabajo sean más complicados. Comandos como git bisect y git log vuelven un poco less útiles; El seguimiento de la historia y los errores se vuelven un poco más difíciles. Los nuevos desarrolladores tienen que aprender un poco más para comenzar a codificar. Por experiencia personal: recorre este path con cuidado. Si sus sub-repos están muy entrelazados, volverá aquí en un año escribiendo esta respuesta para alguien más que busca fracturar su proyecto, como una versión de Git con problemas de Pay It Forward.