Diseño de repository GIT para server con múltiples proyectos

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

\main \ProductA \ProductB \Shanetworking 

entonces

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

Como nuevo usuario de git, quiero explorar un poco 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 tree del proyecto. Entonces podría hacer una de dos cosas.

  1. Configure un proyecto separado para cada Producto.
  2. Configure un único proyecto masivo y almacene productos en subcarpetas.

Hay dependencies entre los productos, por lo que el único proyecto masivo parece apropiado. Utilizaremos un server donde todos los desarrolladores puedan compartir su código. Ya tengo esto funcionando sobre SSH y HTTP y esa parte que amo. Sin embargo, los repositorys en SVN ya tienen muchos GB de tamaño, por lo que arrastrar todo el repository en cada máquina parece una mala idea, especialmente porque se nos factura un excesivo ancho de banda de networking.

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

¿Hay alguna guía o mejores prácticas para trabajar con repositorys de proyectos múltiples muy grandes?

La guía es simple, con respecto a los límites de Git :

  • un repo por proyecto
  • un proyecto principal con submodules .

La idea no es almacenar todo en un repository gigante de git, sino build un pequeño repository como proyecto principal, que hará reference a los compromisos correctos de otros repositorys, cada uno representando un proyecto o componente común propio.


El OP Paul Alexander comenta :

Esto suena similar al soporte "externo" provisto por la subversión.
Probamos esto y nos pareció extremadamente engorroso actualizar constantemente las references de versión en los externos ya que los proyectos se desarrollan simultáneamente con dependencies entre sí. ¿Hay otra opción?

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

  • desarrolle sus subproyectos directamente desde el proyecto principal (como se explica en " Naturaleza verdadera de los submodules "),
  • o hace reference en un sub-repo de un origin hacia el mismo sub-repo desarrollado en otra parte: desde allí solo tiene que extraer de ese sub-repo los cambios realizados en otra parte.

En ambos casos, no olvides comprometer el proyecto principal para registrar la nueva configuration. No hay propiedad "externa" para actualizar aquí. Todo el process es mucho más natural.

Honestamente, esto suena como un verdadero dolor y cualquier cosa que requiera que los desarrolladores hagan algo manualmente cada vez será una fuente habitual de errores y mantenimiento.
Supongo que searché automatizar esto con algunos guiones en el súper proyecto.

Respondí:

Honestamente, puede que tengas razón … eso es hasta la última versión de Git 1.7.1 .
git diff y git status aprendieron a tener en count los estados de los submodules incluso si se ejecutan desde el proyecto principal.
Simplemente no puede perderse la modificación del submodule.

Habiendo dicho eso:

  • los submodules son diferentes de los externos de SVN: ver " ¿Por qué los submodules de Git son incompatibles con SVN Externals? "
  • administrar submodules puede ser complicado: ver " ¿Cómo funciona exactamente el submodule git? ".

GitSlave le permite administrar varios repositorys independientes como uno solo. Cada repos puede ser manipulado por commands regulares de git, mientras que gitslave te permite ejecutar un command adicional sobre todos los repos.

 super-repo +- module-a-repo +- module-b-repo gits clone url-super-repo gits commit -a -m "msg" 

Repo-per-project tiene ventajas con componentes y construcciones simplificadas con herramientas como Maven. Repo-per-project agrega protección al limitar el scope de lo que el desarrollador está cambiando, en términos de errores en el envío de basura.