¿Modelo simple de gitflow con múltiples repositorys sin submodules / subtree?

Tenemos una estructura similar a la de Mejores Prácticas para Repositorios Git con múltiples proyectos en el layout tradicional de n niveles , con los siguientes repositorys:

Shanetworking ProjA ProjB 

Donde ProjA y ProjB son desarrollados por equipos separados de 2-3 personas, usando y algunas veces contribuyendo a Shanetworking .

Pensamos en un model simple que no requiere subtree o submodules, debido a tantos sustos que leímos acerca de esos 2. ¿Puede revisar y dejarnos saber si algo así funcionaría?

  • Cada Proj y también Shanetworking cada uno vive en un repository separado, siguiendo el model de gitflow
  • Jenkins buildá con lo último de la twig de develop de los 3 repos
  • release.sh de un Proj se fusionaría para master tanto Proj como Shanetworking , crear una label en ambos y Jenkins crear y desplegar desde master .

¿Puede esto funcionar? Tenga en count que somos solo 8 personas, y que estamos migrando a git, por lo que nos gustaría mantener las cosas lo más simples posible, de modo que si podemos evitar la curva de aprendizaje de submodules y subtreees, seríamos más felices. O lo haríamos?

Puede funcionar, siempre que ProjA y ProjB conserven en algún lugar (ya sea en un file de text versionado o como git notes ) las references exactas de Shanetworking .

La idea detrás de un progtwigdor de compilation es la reproducibilidad : una herramienta de este tipo debe ser capaz de reproducir la configuration exacta (es decir, la list de references SHA1) utilizada para una compilation determinada.
Eso permite volver a visitar una construcción más adelante.

Siento que su problema no es la estructuración, sino que las dependencies de los proyectos, por ejemplo SVN, no le harían la vida más fácil.

Si tiene dos proyectos que dependen de un proyecto compartido, creo que no debe escaping de especificar eso.

¿Qué pasa si alguien del equipo B cambia compartido justo antes del lanzamiento del Proyecto A? Es posible que obtenga un cambio no deseado en el proyecto A.

Para superar esto, debes usar el control de versiones del proyecto, aquí los submodules de git vienen al rescate, el submodule es una dependencia entre el proyecto X y un punto específico en el time de compartición .

Una alternativa a los submodules de git es la dependencia de la versión de artefactos, en la mayoría (todos) de los idiomas modernos se puede hacer eso. Por ejemplo, en Java, usaría maven / ivy / gradle para definir las dependencies del proyecto. (Deberá cargar compartido en algún repository de artefactos)

No diría que la alternativa es más simple que los submodules de git, sin embargo, es (¿debe?) La forma de ir cuando la estructura del proyecto se vuelve más compleja, con muchos artefactos que dependen unos de otros.