¿Cómo configuro mis repositorys git para poder reutilizar proyectos en Visual Studio fácilmente?

Mi problema puede describirse mejor con un ejemplo.

Supongamos que tengo un proyecto "A".

También tengo un proyecto "B" que depende de "A".

Otro proyecto "C" también depende de "A".

Mi proyecto "principal" depende de "B" y "C". También puede ser que también dependa directamente de "A".

Se parece un poco al "temido diamante de la inheritance" cuando "principal" == "D"

temido diamante de la herencia

Estos son mis requisitos:

  • Me gustaría poder editar el contenido de los proyectos "A", "B" y "C" en la solución para "principal" y enviar cambios (es decir, no solo quiero include el file DLL sino también el código ) Pero dado que "B" y "C" dependen de "A", se debe exigir que hagan reference al mismo compromiso.

  • Los proyectos "A", "B" y "C" muy probablemente también serán referencedos por otros proyectos, por lo que no puedo asumir la propiedad del directory de trabajo para el proyecto "principal".

  • También debería ser posible sincronizar los repositorys para cada proyecto con repositorys externos.

  • Los proyectos "A", "B", "C" y "principal" deben ser

¿Cómo necesito configurar mis repositorys para lograr esto?

No use (ab) git o cualquier sistema de control de versiones para esto.

Usa NuGet .

No desea include directamente otros proyectos. En su lugar, empackage cada dependencia en un package .nuget y utilícelo para el event handling dependencies. Si bien los submodules parecen una solución al problema, en la práctica, es mucho mejor utilizar una administración de dependencies adecuada en lugar de simplemente include otros proyectos.

TeamCity y otros sistemas de CI, incluso TFS, le permiten crear automáticamente nuevos packages nuget, y TeamCity también puede actuar como un server nuget.

Y si no quiere usar un server NuGet 'real', también puede usar una unidad compartida en algún lugar de su intranet.

Utilizando el enfoque de submodules , recomendaría un model que incluye una list de dependencies, en lugar de una jerarquía de dependencies:

Cree un repository " parent ", en el que " git submodule add " los submodules para D , C , B y A :

 parent D C B A 

Agregue cualquier enlace simbólico ( incluso en Windows ) que necesite para que cada proyecto se compile (es decir, para encontrar las fonts de sus dependencies desde su propia estructura).

El repository " parent " hará reference a la list exacta de SHA1 que representa cada dependencia en su versión exacta necesaria para que el proyecto se compile / ejecute en un momento específico en el historial del repository principal.

Y, como explico en "la verdadera naturaleza de los submodules ", puede hacer cualquier modificación que desee en A , B , C o D , e impulsar a su respectivo repository ascendente .
Pero no debe olvidar regresar al repository parent , agregar y confirmar las modificaciones SHA1 que representan el nuevo estado de los repositorys A , B , C y D dependientes.

Este es un enfoque de componentes , que tiene la ventaja de resolver cualquier dependencia superpuesta: si B y C necesitan una versión diferente de A , el repository parent tendrá que elegir una (y solo una) versión de A

Para agregar a la respuesta de OP Onur:

Las dependencies deben ser relativas

No necesariamente: puede agregar un enlace simbólico dentro de un submodule, si necesita ver otro con una ruta fija.

Crear el repository " user "

¿Cómo reviso automáticamente el set correcto de bibliotecas, por ejemplo, A y B en la configuration anterior?

Una vez que haya determinado la versión inicial válida para A y B, puede crear y enviar una twig dedicada para su uso en un context "principal".
Luego haces que esos submodules sigan esa twig , lo que significa que cualquier git submodule update --remote searchá el último SHA1 de esa twig dedicada para los submodules A y B

Solo para asegurarme de que entiendo tu enfoque:

Cosas que necesito hacer para configurar el repository de la biblioteca:

  1. Crear el repository "principal"
  2. Crea un submodule para cada biblioteca
  3. Las dependencies deben ser relativas, es decir, si D depende de B, la ruta debe ser similar a la carpeta ../../B/
  4. Cada confirmación en el repository principal representa una combinación válida de bibliotecas

Cosas que debo hacer para include un set de bibliotecas elegidas en un nuevo proyecto:

  1. Crear el repository "usuario"
  2. Cree una twig en las bibliotecas requeridas respectivos repositorys (por ejemplo, A y B) como "para_usuario" y realice un seguimiento de esto para los submodules en el proyecto de "usuario".
  3. Cree una twig "from_user" en el repository "principal" que rastrea los cambios de las bibliotecas usadas (¿ es posible rastrear las twigs del repository en una base por twig? ).
  4. Incluya el set de bibliotecas elegido, por ejemplo, A y B de la twig "for_user".
  5. Los cambios realizados en A y / o B van a esta twig y pueden fusionarse en la twig principal "principal" si es adecuado y / o combinarse en otras twigs "de _…" de otros proyectos que utilizan estas bibliotecas. El proyecto "principal" se usa para crear sets coherentes de bibliotecas.

Efectivamente, esto significa que cada proyecto de "usuario" que utiliza estas bibliotecas está representado por una twig "desde _…" en el repository "principal" y una twig "por _…" en cada repository de bibliotecas usadas.

La configuration ahora debería verse así

 A branch "for_user" branch "master" (== for_parent) <other branches for each project using this library> B,C,D <like A> parent submodule A - tracks branch dependent on the current branch submodule B - tracks branch dependent on the current branch <other submodules> branch "master" (== from_parent) branch "from_user" <other branches for each project using one of the libraries> user <own stuff> submodule A - tracks branch "for_user" submodule B - tracks branch "for_user" 

Preguntas abiertas:

  • ¿Cómo reviso automáticamente el set correcto de bibliotecas, por ejemplo, A y B en la configuration anterior? Podría revisar todas las bibliotecas disponibles, pero eso de alguna manera eliminaría la necesidad de submodules separados para cada biblioteca