Лучшая практика для Git Хранилища с несколькими проектами в традиционном дизайне n-уровня

Я делаю переход от централизованной системы SCM до GIT. Хорошо, я признаю, что это Visual SourceSafe. Таким образом, помимо того, что вы преодолеваете кривую обучения команд и рабочих процессов Git, самая большая проблема, с которой я сейчас сталкиваюсь, заключается в том, как перенести наш текущий репозиторий на Git в отношении одного или нескольких ароматов нескольких репозиториев.

Я задавал этот вопрос разными способами, но обычно просто базовый... "У меня есть приложения, которые хотят поделиться некоторыми библиотеками более низкого уровня", а консервированный ответ всегда "использует отдельные репозитории" и/или "использовать подмодули Git" без особого объяснения того, когда/почему этот шаблон следует использовать (что он преодолевает, что его устраняет?) Из моих ограниченных знаний/чтений на Git до сих пор кажется, что подмодули могут иметь своих собственных демонов для битвы, особенно для кого-то нового для GIT.

Тем не менее, я еще не вижу, чтобы кто-то вопиюще спросил: "Когда у вас есть традиционная разработка n-уровня (пользовательский интерфейс, бизнес, данные, а затем общие инструменты), где каждый уровень является собственным проектом, следует ли использовать один или несколько репозиториев?" Мне это непонятно, потому что почти всегда, когда добавляется новая "функция", изменения кода пульсируют через каждый уровень.

Чтобы усложнить ситуацию в отношении Git, мы дублировали эти слои в рамках "фреймворков", чтобы сделать более управляемые проекты/компоненты с точки зрения разработчика. В целях этой дискуссии позвольте назвать эту коллекцию проектов/слоев "Таити", которая представляет собой целый "продукт".

Последний "слой" в нашей настройке - это добавление клиентских веб-сайтов/проектов, которые настраивают/расширяют Таити. Представление этого в структуре папок может выглядеть следующим образом:

/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

После объяснения того, как мы расширили традиционный дизайн n-уровня с несколькими проектами, я ищу любой опыт в отношении того, какое решение вы приняли с аналогичной ситуацией (даже простой интерфейс, бизнес, разделение данных все, что вы использовали), и что было легче/сложнее из-за вашего решения. Правильно ли я в своем предварительном чтении о том, как подмодули могут быть немного больными? Больше боли, чем того стоит?

Моя реакция кишки на один репозиторий для Tahiti (все проекты, исключая "клиентские проекты" ), а затем один репозиторий для каждого клиента. Весь источник Таити, который я предполагаю, должен быть < 10k файлов. Вот мои рассуждения (и я приветствую критику)

Мне кажется, что в Git вы хотите отслеживать историю "особенностей" по сравнению с отдельными "проектами/файлами", и даже при нашем разделении проектов "функция" всегда будет охватывать несколько проектов.
"Функция", закодированная на основном сайте, почти всегда будет минимально влиять на основной сайт и все проекты для "рамки" (например, CoreWebsite, Framework1.Business, Framework1.Data).
Функция может легко охватывать несколько фреймворков (я бы сказал, что 10% реализованных функций будут охватывать рамки - CoreWebsite, Framework1.Business, Framework1.Data, Framework2.Business, Framework2.Data).
Аналогичным образом, функция может потребовать внесения изменений в 1 или более проектов SharedLib и/или проектов "помощник веб-сайта".
Изменения в клиентском пользовательском коде почти всегда будут локальны для их репозитория и не требуют отслеживания изменений других компонентов, чтобы увидеть, что такое "полный набор изменений функций".
Учитывая, что функция охватывает проекты, чтобы увидеть всю область действия, если каждый проект был его собственным репозиторием, кажется, было бы болью попытаться проанализировать все * изменения кода в репозиториях?

Спасибо заранее.

Ответ 1