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

Estoy haciendo el cambio de un sistema SCM centralizado a GIT. Bien, admito cuál, es Visual SourceSafe. Así que, además de superar la curva de aprendizaje de los comandos y el flujo de trabajo de Git, el mayor problema al que me enfrento actualmente es cómo migrar nuestro repositorio actual a Git en lo que respecta a un solo o algún tipo de repositorios múltiples.

He visto esta pregunta hecha en una variedad de maneras, pero normalmente solo la básica..."Tengo aplicaciones que quieren compartir algunas bibliotecas de nivel inferior "y la respuesta enlatada siempre es" usar repositorios separados "y/o" usar submódulos de Git " sin mucha explicación de cuándo/por qué se debe usar este patrón (¿qué supera, qué elimina?) De mi limitado conocimiento/lectura sobre Git hasta ahora, parece que los submódulos pueden tener sus propios demonios para luchar, especialmente para alguien nuevo en Git.

Sin embargo, lo que todavía tengo que ver a alguien preguntar descaradamente es: "Cuando tienes el desarrollo tradicional de n-tier (UI, Negocios, Datos y luego Herramientas compartidas) donde cada capa es su propio proyecto, ¿debería usar uno o varios repositorios?"No está claro para mí porque casi siempre, cuando se agrega una nueva 'característica', los cambios de código se ondulan a través de cada capa.

Para complicar las cosas con respecto a Git, hemos duplicado estas capas a través de 'frameworks' para hacer proyectos/componentes más manejables desde la perspectiva de un desarrollador. Para el propósito de esta discusión, vamos a llamar a estos colección de proyectos/capas 'Tahití', que representa todo un 'producto'.

La 'capa' final en nuestra configuración es la adición de sitios web/proyectos de clientes que personalizan/expanden Tahití. Representar esto en una estructura de carpetas podría verse mejor como:

/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 ampliado el diseño tradicional de n-tier con múltiples proyectos, estoy buscando cualquier experiencia sobre qué decisión 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/difícil debido a tu decisión. ¿Tengo razón en mi lectura preliminar sobre cómo los submódulos pueden ser un poco de dolor? Más dolor de lo que vale la pena el beneficio?

Mi reacción inmediata es un repositorio para Tahití (todos los proyectos excluyendo los 'proyectos cliente'), luego un repositorio para cada cliente. Supongo que toda la fuente de Tahití tiene que ser

• Me parece que en Git quieres para rastrear el historial de' características 'vs' proyectos/archivos ' individuales, e incluso con nuestra separación de proyectos, una 'característica' siempre abarcará varios proyectos.
• Una 'característica' codificada en el sitio principal casi siempre afectará mínimamente al sitio web principal y a todos los proyectos para un 'framework' (es decir, CoreWebsite, Framework1.Negocios, Framework1.Datos)
• Una característica puede abarcar fácilmente múltiples marcos (yo diría que el 10% de las características que implementamos abarcarían marcos: CoreWebsite, Framework1.Negocio, Marco Marco1.Datos, marco 2.Negocios, Framework2.Datos)
• De manera similar, una característica podría requerir cambios en 1 o más proyectos de SharedLib y/o los proyectos 'UI website helper'.
• Los cambios en el código personalizado del cliente casi siempre solo serán locales en su repositorio y no requerirán el seguimiento de los cambios en otros componentes para ver cuál era el 'conjunto completo de cambios de características'.
• 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 para tratar de analizar* todos * cambios de código a través de repositorios?

Gracias de antemano.