visual studio - utilizar - Las mejores prácticas para los repositorios Git con múltiples proyectos en el diseño tradicional de n niveles

tutorial como utilizar git en visual studio code (1)

Estoy haciendo el cambio de un sistema SCM centralizado a GIT. OK, voy a admitir 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 estoy enfrentando actualmente es cómo migrar nuestro repositorio actual a Git en relación con uno o varios tipos de repositorios.

He visto esta pregunta planteada de varias maneras, pero normalmente solo la básica ... "Tengo aplicaciones que desean compartir algunas bibliotecas de nivel inferior" y la respuesta enlatada siempre es "usar repositorios separados" y / o "usar Los 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 conocimiento / lectura limitados de Git hasta ahora, parece que los submódulos pueden tener sus propios demonios para la batalla, Especialmente para alguien nuevo en Git.

Sin embargo, lo que aún no veo a alguien que pregunte descaradamente es: "Cuando tiene el desarrollo tradicional de n niveles (IU, Negocio, Datos y luego Herramientas compartidas) donde cada capa es su propio proyecto, debe usar uno o varios. repositorios? " No me queda claro porque casi siempre, cuando se agrega una nueva ''característica'', los cambios de código se propagan 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 estos 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 se personalizan / expanden en Tahití. Representar esto en una estructura de carpetas podría verse 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 expandido el diseño tradicional de n niveles con múltiples proyectos, busco cualquier experiencia sobre qué decisión ha tomado con una situación similar (incluso la simple interfaz de usuario, Negocios, Separación de datos fue todo lo que necesitó). utilizado) y lo que fue más fácil / difícil debido a su decisión. ¿Tengo razón en mi lectura preliminar sobre cómo los submódulos pueden ser un poco de dolor? ¿Más dolor del que vale la pena el beneficio?

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

Me parece que en Git desea realizar un seguimiento del historial de ''características'' frente a ''proyectos / archivos'' individuales, e incluso con nuestra separación de proyectos, una ''característica'' siempre abarcará múltiples proyectos.
Una "característica" codificada en el sitio central casi siempre tendrá un efecto mínimo en el sitio web central y en todos los proyectos para un "marco" (es decir, CoreWebsite, Framework1.Business, Framework1.Data)
Una característica puede abarcar fácilmente varios marcos (yo diría que el 10% de las características que implementamos abarcarían marcos: CoreWebsite, Framework1.Business, Framework1.Data, Framework2.Business, Framework2.Data)
De manera similar, una característica podría requerir cambios en 1 o más proyectos SharedLib y / o en los proyectos del ''ayudante del sitio web de UI''.
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 fue el "conjunto completo de cambios de características".
Dado que una característica abarca proyectos para ver el alcance completo, si cada proyecto fuera su propio repositorio, parece que sería una molestia tratar de analizar * todos * los cambios de código en los repositorios.

Gracias por adelantado.

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 otros), no hay razón para que alguien actualice la base del código completo. Simplemente pueden obtener los cambios de los proyectos que les interesan.

Los submódulos 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 distintas 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 garantiza que todas las actualizaciones del repositorio / Core se incorporen al repositorio de UI Layer. También significa que si tiene que actualizar sus bibliotecas compartidas, no tiene que hacerlo entre 5 y 6 proyectos.