Mejores prácticas para repositorios Git con múltiples proyectos en el diseño tradicional de n niveles

Question

Estoy haciendo el cambio de un sistema SCM centralizado a GIT. OK, admitiré cuál, es Visual SourceSafe. Por lo tanto, además de superar la curva de aprendizaje de los comandos y el flujo de trabajo de Git, el problema más importante que estoy enfrentando actualmente es cómo migrar nuestro repositorio actual a Git en lo que respecta al sabor único o de varios repositorios.

He visto esta pregunta de varias maneras, pero normalmente solo la básica ... "Tengo aplicaciones que desean compartir algunas bibliotecas de nivel inferior" y la respuesta enlatada es siempre "usar repositorios separados" y/o "use submódulos de Git" sin mucha explicación de cuándo/por qué debería usarse este patrón (qué es lo que supera, ¿qué elimina?) De mi limitado conocimiento/lectura en Git hasta ahora, parece que los submódulos pueden tener su propio demonios a la batalla, especialmente para alguien nuevo en Git.

Sin embargo, lo que todavía tengo que ver con alguien descaradamente es: "Cuando tienes el desarrollo tradicional de n niveles (UI, Business, Data y Shared Tools) donde cada capa es su propio proyecto, ¿deberías usar uno o varios repositorios? " No está claro para mí porque casi siempre, cuando se agrega una nueva 'característica', el código cambia ondulando a través de cada capa.

Para complicar las cosas con respecto a Git, hemos duplicado estas capas en 'marcos' para hacer proyectos/componentes más manejables desde la perspectiva de un desarrollador. Para el propósito de esta discusión, llamemos a esta colección de proyectos/capas 'Tahiti', que representa un 'producto' completo.

La 'capa' final en nuestra configuración es la adición de sitios web/proyectos de clientes que personalizan/expanden sobre Tahiti. Que representa esto en una estructura de carpetas podría mejor aspecto:

/Clients 
    /Client1 
    /Client2 

/UI Layer 
    /CoreWebsite (views/models/etc) 
    /WebsiteHelper (contains 'web' helpers appropriate for any website) 
    /Tahiti.WebsiteHelpers (contains 'web' helpers only appropriate for Tahiti sites) 

/BusinessLayer (logic projects for different 'frameworks') 
    /Framework1.Business 
    /Framework2.Business 

/DataLayer 
    /Framework1.Data 
    /Framework2.Data 

/Core (projects that are shared tools useable by any project/layer) 
    /SharedLib1 
    /SharedLib2 

Después de explicar cómo hemos expandido en el diseño tradicional de n niveles con múltiples proyectos, estoy buscando ninguna experiencia en lo que decisión que ha tomado con una situación similar (incluso la simple interfaz de usuario, negocio, separación de datos fue todo lo que usaste) y lo que fue más fácil/más difícil debido a tu decisión. ¿Tengo razón en mi lectura preliminar sobre cómo los submódulos pueden ser un poco dolorosos? Más dolor de lo que vale la pena el beneficio?

Mi reacción intuitiva es a un repositorio de Tahiti (todos los proyectos excluyendo los 'proyectos de clientes'), luego un repositorio para cada cliente. Toda la fuente de Tahití que supongo tiene que ser < 10k archivos. Aquí es mi razonamiento (y bienvenida la crítica)

• Me parece que en Git desea realizar un seguimiento historia de 'características' vs 'proyectos/ficheros' individuales, e incluso con nuestra separación proyecto, un ' la característica 'siempre abarcará múltiples proyectos.
• Una 'característica' codificado en el sitio central casi siempre mínimamente efectuar el sitio web de núcleo y todos los proyectos para un 'marco' (es decir CoreWebsite, Framework1.Business, Framework1.Data)
• Una característica puede abarcar fácilmente múltiples marcos (Diría que el 10% de las funciones que implementamos abarcarían frameworks: CoreWebsite, Framework1.Business, Framework1.Data, Framework2.Business, Framework2.Data)
• De forma similar, una función podría requerir cambios en 1 o más proyectos SharedLib y/o los proyectos 'UI web helper'.
• Los cambios en el código personalizado del cliente casi siempre serán locales en su repositorio y no requieren cambios de seguimiento en otros componentes para ver cuál fue el "conjunto de cambios de características completos".
• Dado que una característica abarca proyectos para ver todo el alcance, si cada proyecto era su propio repositorio, parece que sería un dolor tratar de analizar * todos * los cambios de código en los repositorios?

Gracias de antemano.

Answer 1

La razón por la que la mayoría de las personas aconseja hacer repositorios separados es porque separa los cambios y los conjuntos de cambios. Si alguien realiza un cambio en los proyectos del cliente (que usted dice que realmente no afecta a los demás), no hay ninguna razón para que alguien actualice la base de códigos completa. Simplemente pueden obtener los cambios de los proyectos que les interesan.

Los submódulos de Git son como Externos en Subversion. Puede configurar sus repositorios git para que cada uno sea una capa separada, y luego usar submódulos para incluir los proyectos que se necesitan en las diversas jerarquías que tiene.

Así que si por ejemplo:

/Core -- It's own git repository that contains it's base files (as you had outlined) 
    /SharedLib1 
    /SharedLib2 

/UI Layer -- Own git repository 
    /CoreWebsite 
    /WebsiteHelper 
    /Tahiti.WebsiteHelpers 
    /Core -- Git Submodule to the /Core repository 
    /SharedLib1 
    /SharedLib2 

Esto asegura que las actualizaciones en el repositorio/Core se ponen en repositorio de interfaz de usuario de capa. También significa que si tiene que actualizar sus bibliotecas compartidas, no tiene que hacerlo en 5-6 proyectos.