Diseño de repositorio GIT para servidor con múltiples proyectos

Una de las cosas que me gusta de la forma en que configuré Subversion es que puedo tener un único repositorio principal con múltiples proyectos. Cuando quiero trabajar en un proyecto, puedo consultar solo ese proyecto. Me gusta esto

\main
    \ProductA
    \ProductB
    \Shared

luego

svn checkout http://.../main/ProductA

Como nuevo usuario de git, quiero explorar un poco de las mejores prácticas en el campo antes de comprometerme con un flujo de trabajo específico. Por lo que he leído hasta ahora, git almacena todo en una sola carpeta .git en la raíz del árbol del proyecto. Entonces podría hacer una de dos cosas.

1. Configure un proyecto separado para cada producto.
2. Configure un solo proyecto masivo y almacene los productos en subcarpetas.

Existen dependencias entre los productos, por lo que el proyecto masivo único parece apropiado. Usaremos un servidor donde todos los desarrolladores pueden compartir su código. Ya tengo esto funcionando a través de SSH y HTTP y esa parte me encanta. Sin embargo, los repositorios en SVN ya tienen muchos GB de tamaño, por lo que arrastrar todo el repositorio en cada máquina parece una mala idea, especialmente porque se nos factura por un ancho de banda de red excesivo.

Me imagino que los repositorios del proyecto del kernel de Linux son igualmente grandes, por lo que debe haber una forma adecuada de manejar esto con Git, pero aún no lo he descubierto.

¿Existen pautas o mejores prácticas para trabajar con repositorios de proyectos múltiples muy grandes?

La pauta es simple, en lo que respecta a los límites de Git :

• un repositorio por proyecto
• un proyecto principal con submódulos .

La idea no es almacenar todo en un repositorio gigante de git, sino construir un pequeño repositorio como proyecto principal, que hará referencia a las confirmaciones correctas de otros repositorios, cada uno representando un proyecto o componente común propio.

El OP Paul Alexander comenta :

Esto suena similar al soporte "externo" proporcionado por Subversion.
Probamos esto y nos resultó extremadamente engorroso actualizar constantemente las referencias de versión en los externos, ya que los proyectos se desarrollan simultáneamente con dependencias entre sí. Hay otra opcion ??

@Paul: sí, en lugar de actualizar la versión del proyecto principal, usted:

• Desarrolle sus subproyectos directamente desde el proyecto principal (como se explica en " Verdadera naturaleza de los submódulos "),
• o hace referencia en un sub-repositorio originhacia el mismo sub-repositorio que se está desarrollando en otro lugar: a partir de ahí, solo tiene que extraer de ese sub-repositorio los cambios realizados en otro lugar.

En ambos casos, no debe olvidarse de confirmar el proyecto principal, para registrar la nueva configuración. No hay propiedad "externa" para actualizar aquí. Todo el proceso es mucho más natural.

Honestamente, esto suena como una verdadera molestia y cualquier cosa que requiera que los desarrolladores hagan algo manualmente cada vez será una fuente regular de errores y mantenimiento.
Supongo que buscaré automatizar esto con algunos scripts en el superproyecto.

Respondí:

Honestamente, es posible que haya tenido razón ... eso es hasta la última versión 1.7.1 de Git .
git diffy git statusambos aprendieron a tener en cuenta los estados de los submódulos incluso si se ejecutaban desde el proyecto principal.
Simplemente no puede perderse la modificación del submódulo.

Habiendo dicho eso:

• los submódulos son diferentes de los externos de SVN: consulte " ¿Por qué los submódulos de git son incompatibles con los externos de svn? "
• administrar submódulos puede ser complicado: consulte " ¿Cómo funciona exactamente el submódulo git? ".

GitSlave le permite administrar varios repositorios independientes como uno. Cada repositorio puede ser manipulado por comandos de git regulares, mientras que gitslave le permite ejecutar adicionalmente un comando en todos los repositorios.

super-repo
+- module-a-repo
+- module-b-repo

gits clone url-super-repo
gits commit -a -m "msg"

Repo-per-project tiene ventajas con la creación de componentes y las compilaciones simplificadas con herramientas como Maven. Repo-per-project agrega protección al limitar el alcance de lo que el desarrollador está cambiando, en términos de confirmaciones erróneas de basura.