GIT diseño repositorio de servidor con varios proyectos

Question

Una de las cosas que me gustan de la manera que tengo de Subversion configuración es que puedo tener un único repositorio principal con múltiples proyectos. Cuando quiero trabajar en un proyecto, puedo verificar solo ese proyecto. Al igual que este

\main 
    \ProductA 
    \ProductB 
    \Shared 

continuación

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

Como nuevo usuario a git quiero explorar un poco de las mejores prácticas en el campo antes de comprometerse a 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 productos en subcarpetas.

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

Me imagino que los repositorios de proyectos kernel de Linux son igual de grande, así que debe ser una forma adecuada de manejar esto con Git, pero simplemente no han descubierto todavía.

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

Answer 1

La directriz es simple, en lo que respecta a Git limits:

• una cesión temporal por proyecto
• un proyecto principal, con submodules.

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

---

El OP Paul Alexandercomments:

Esto suena similar a la de apoyo "externo" proporcionado por la subversión.
Hemos intentado esto y nos pareció extremadamente engorroso actualizar constantemente las referencias de versión en el exterior ya que los proyectos se desarrollan simultáneamente con dependencias entre sí. ¿Hay otra opción?

@ Pablo: sí, en lugar de actualizar la versión del proyecto principal, que o bien:

• desarrollar sus subproyectos directamente desde dentro del proyecto principal (como se explica en "True Nature of submodules"),
• o hace referencia en un sub-repo origin hacia el mismo sub-repo desarrollado en otro lugar: a partir de ahí solo tiene que sacar de ese sub-repo los cambios realizados en otro lugar.

En ambos casos, no debe olvidar comprometer 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 un dolor real y cualquier cosa que requiera que los desarrolladores hagan algo manualmente siempre será una fuente habitual de errores y mantenimiento.
Supongo que buscaré la automatización de esto con algunos scripts en el súper proyecto.

me respondió:

Honestamente, es posible que tenga razón ... es decir, hasta la última Git release 1.7.1.
git diff y git status 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.

Dicho esto:

• submódulos son diferentes de lo externo SVN: ver "Why are git submodules incompatible with svn externals?"
• gestión submódulos puede ser complicado: véase "How exactly does git submodule work?".

Answer 2

GitSlave le permite gestionar varios repositorios independientes como uno solo. Cada repos puede ser manipulado por comandos regulares de git, mientras que gitslave te permite ejecutar un comando adicional sobre todos los repos.

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

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

Repo-por-proyecto tiene ventajas con componentes y construcciones simplificadas con herramientas como Maven. Repo-por-proyecto agrega protección al limitar el alcance de lo que el desarrollador está cambiando, en términos de confusiones erróneas de basura.