visual studio git solution project locura

Así que estoy tratando de encontrar la mejor manera de estructurar mis repositorys git con mis proyectos de aplicaciones web .net y proyectos de database mientras uso git y estoy realmente luchando.

Estamos utilizando el flujo de trabajo de ramificación de características y la continuous integration con las twigs principales de desarrolladores y maestros actualmente.

Así que aquí está el escenario … digamos que tengo 6 proyectos. (3 web y 3 bases de datos)

websiteA (tiene consultas a la database1) websiteB (tiene consultas a la database2) websiteC (tiene consultas a la database1, la database2 y la database3)

database1 (references database2) database2 (references database1) database3 (references database1 y database2)

todos los proyectos se pueden implementar de forma independiente, aunque hay muchas ocasiones en que deben implementarse juntos.
(sí, sé que esto es un desastre y debe ser limpiado).

Mi pregunta es cómo estructurarías los repositorys git. Aquí hay algunas opciones que he considerado.

  1. Git repo con solución para cada uno? Parece que esto sería más modular y less ruidoso en el repository, pero se necesita más coordinación cuando se presiona el código db y el código web.

  2. un gran repo git con todos los proyectos en ellos? Parece que esto es un poco más fácil de poder trabajar en múltiples proyectos al mismo time sin tener que sincronizar tanto.

  3. submodules de git o subtree de git? (Preocupados por esto, ya que muchos de los desarrolladores son nuevos en git y estos parecen ser un poco más complicados para mí).

  4. ¿otras opciones? ¿Alguna idea? Aprecio tu ayuda.

Creo que un gran repository con todos los proyectos es, al less por el momento, el path a seguir ( monorepositorys )

Porque: * más fácil de configurar * más fácil de usar, especialmente como dices, cuando todos tus usuarios no tienen mucha experiencia

Vaya con eso y gane experiencia y extraiga los submodules más tarde si lo considera apropiado (y cuando los desarrolladores tienen más experiencia en usar git)

Creo que tener varios repositorys o subtreees tiene sentido si las dependencies solo pueden cambiar durante las versiones. Por ejemplo, un module de python depende de los builtins y otros modules de python, pero vive en su propio repository porque las dependencies solo cambian durante las versiones.

Entonces, creo que la respuesta necesitaría saber cuán estrechamente relacionados están estos sistemas.

Algunas preguntas que puedes pensar son:

  1. ¿Cambiará en un código de causa DB schema para romperse en un proyecto que no depende directamente de él? ¿O interactúan a través de API y esto no afectará a nada más que a la dependencia directa?
  2. Los submodules tienen sentido cuando los proyectos se usan como bibliotecas, pero desean mejorar continuamente las características entre sí. ¿Es esta la situación en la que te encuentras?