Лучшие практики для Git Repositories с несколькими проектами в традиционном n-уровневом дизайне - PullRequest
29 голосов
/ 01 апреля 2011

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

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

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

Чтобы усложнить ситуацию с 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

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

Моя внутренняя реакция - один репозиторий для Таити (все проекты, исключая «клиентские проекты»), затем один репозиторий для каждого клиента.Я предполагаю, что весь источник на Таити должен быть <10 тыс. Файлов.Вот мои рассуждения (и я приветствую критику) </p>

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

Заранее спасибо.

1 Ответ

14 голосов
/ 07 апреля 2011

Причина, по которой большинство людей советуют создавать отдельные репозитории, заключается в том, что они разделяют изменения и наборы изменений. Если кто-то вносит изменения в клиентские проекты (которые, как вы говорите, на самом деле не влияют на других), у кого-то нет причин обновлять всю кодовую базу. Они могут просто получить изменения от проекта (ов), который их волнует.

Подмодули Git похожи на Externals в Subversion. Вы можете настроить свои репозитории git таким образом, чтобы каждый из них представлял собой отдельный слой, а затем использовать подмодули для включения проектов, которые необходимы в различные имеющиеся у вас иерархии.

Так, если, например:

/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

Это гарантирует, что любые обновления в хранилище / Core будут перенесены в хранилище UI Layer. Это также означает, что если вам нужно обновить общие библиотеки, вам не нужно делать это в 5-6 проектах.

...