Я перехожу с централизованной системы SCM на GIT. Хорошо, я признаю, что это Visual SourceSafe. Таким образом, в дополнение к преодолению кривой обучения командам и рабочему процессу Git, самая большая проблема, с которой я сейчас сталкиваюсь, заключается в том, как перенести наш текущий репозиторий на Git в отношении одного или нескольких вариантов нескольких репозиториев.
Я видел, как этот вопрос задавали по-разному, но, как правило, только базовый..."У меня есть приложения, которые хотят совместно использовать некоторые библиотеки более низкого уровня", и стандартный ответ всегда "использовать отдельные репозитории" и/или "использовать Git submodules» без особых объяснений того, когда/почему следует использовать этот шаблон (что он преодолевает, что устраняет?). Из моих ограниченных знаний/чтения о Git до сих пор кажется, что у подмодулей могут быть свои собственные демоны, с которыми нужно сражаться, особенно для тех, кто плохо знаком с Git.
Тем не менее, я еще не видел, чтобы кто-то откровенно спрашивал: «Когда у вас традиционная n-уровневая разработка (пользовательский интерфейс, бизнес, данные, а затем общие инструменты), где каждый уровень является отдельным проектом, следует ли вам использовать один или несколько хранилища?" Мне это непонятно, потому что почти всегда, когда добавляется новая «функция», изменения в коде распространяются на каждый уровень.
Чтобы усложнить ситуацию в отношении Git, мы продублировали эти слои во всех «фреймворках», чтобы сделать проекты/компоненты более управляемыми с точки зрения разработчика. Для целей этого обсуждения давайте назовем эту коллекцию проектов/слоев «Таити», которая представляет собой весь «продукт».
Последний «уровень» в нашей настройке — это добавление клиентских веб-сайтов/проектов, которые настраивают/расширяют Tahiti. Представление этого в структуре папок может выглядеть так:
/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 (все проекты, кроме «клиентских проектов»), а затем один репозиторий для каждого клиента. Я предполагаю, что весь источник Таити должен состоять из 10 000 файлов. Вот мои рассуждения (и я приветствую критику)
- Мне кажется, что в Git вы хотите отслеживать историю «функций» по сравнению с отдельными «проектами/файлами», и даже с нашим разделением проектов «функция» всегда будет охватывать несколько проектов.
- «Функция», закодированная на основном сайте, почти всегда минимально влияет на основной сайт и все проекты для «фреймворка» (например, CoreWebsite, Framework1.Business, Framework1.Data).
- Функция может легко охватывать несколько фреймворков (я бы сказал, что 10% функций, которые мы реализуем, будут охватывать фреймворки — CoreWebsite, Framework1.Business, Framework1.Data, Framework2.Business, Framework2.Data).
- Аналогичным образом для функции могут потребоваться изменения в одном или нескольких проектах SharedLib и/или проектах «Помощник веб-сайта пользовательского интерфейса».
- Изменения в пользовательском коде клиента почти всегда будут только локальными для их репозитория и не требуют отслеживания изменений в других компонентах, чтобы увидеть, каков был «весь набор изменений функций».
- Учитывая, что функция охватывает проекты, чтобы увидеть всю область действия, если бы каждый проект был собственным репозиторием, кажется, было бы сложно попытаться проанализировать *все* изменения кода в репозиториях?
Заранее спасибо.
