Подмодуль Git или подрепозиторий или удаленный?

Я использую GIT для управления проектом системы управления контентом (CMS). CMS может иметь несколько плагинов (модулей).

Итак, в основном, я хочу иметь 3 типа репозиториев:

  • Разработка ядра CMS (каждый новый проект является проверкой последней стабильной и ненастроенной версии)
  • 1 репозиторий на модуль/плагин. (каждый новый проект будет проверять последнюю стабильную версию модуля, который они хотят внедрить)
  • 1 репозиторий на проект (каждый клиент будет репозиторием, представляющим персонализацию из основной CMS и модулей)

Для типа 1 и 2, я думаю, это простой базовый репозиторий. Но когда дело доходит до клиентского проекта, я путаюсь:

  • Сначала я клонирую CMS, затем захожу в папку /modules/ и снова клонирую все необходимые модули? Это сделает репозиторий внутри репозитория! Будет ли первое репо пытаться зарегистрировать папку .git/ каждого модуля?
  • Я не могу использовать подмодуль, так как каждому клиенту нужно, чтобы его модули были персонализированы.
  • Если я изменю основной компонент модуля (не для персонализации, а просто для исправления ошибки), могу ли я отправить этот единственный файл в репозиторий исходного модуля?
  • (Не говоря о модуле unitTest, который будет распространяться повсюду)

Итак, вопрос: как мне организовать репозиторий/файлы/папки, чтобы быть эффективным?


git module code-organization project-organization
person FMaz008    schedule 25.03.2011    source источник

Ответы (2)


arrow_upward
13
arrow_downward

Описанный вами макет будет очень хорошо работать с подмодулями git. Я настоятельно рекомендую прочитать документы и попробовать несколько руководства. Ключевое отличие вашего плана заключается в том, что каждый клиентский репозиторий и клиентский репозиторий плагинов будут иметь два пульта дистанционного управления вместо одного. А когда вы захотите начать новый клиентский проект, вам нужно будет

  1. раскошелиться на основную ветку cms
  2. разветвить все плагины, которые будут изменены
  3. клонируйте разветвленный cms из (1), обновите его подмодули, чтобы они указывали на новые пульты из (2)
  4. инициализировать/обновить подмодули
  5. (необязательно) добавьте основной URL-адрес cms в качестве удаленного в разветвленной cms вашего клиента.
  6. (необязательно) добавьте URL-адреса основных плагинов в качестве удаленных в разветвленных плагинах вашего клиента.

Лучшим вариантом может быть использование одного и того же репозитория и просто создание ветки для каждого клиента. Вот как бы я это сделал.

person John Douthat    schedule 25.03.2011
comment
Что ж, я прочитал подмодуль справки git, и они говорят: их не следует путать с пультами, которые предназначены в основном для веток одного и того же проекта; подмодули предназначены для разных проектов, которые вы хотели бы сделать частью своего исходного дерева, в то время как история двух проектов по-прежнему остается полностью независимой, и вы не можете изменять содержимое подмодуля из основного проекта. ... в моем случае я хочу изменить подмодуль внутри клиентского проекта на случай, если мне понадобится персонализировать плагин. Теперь вы говорите мне, что мы можем модифицировать подмодули? - person FMaz008; 27.03.2011
comment
да. Измените код подключаемого модуля клиента, зафиксируйте и отправьте изменения в (2), затем перейдите к коду CMS клиента, зафиксируйте и отправьте изменение в подключаемый модуль (обновляет хэш SHA) до (1). - person John Douthat; 28.03.2011
comment
Хорошо, звучит как хороший ответ, но у меня все еще есть 1 дополнительный вопрос, касающийся организации/структуры папок: stackoverflow.com/questions/5461617/ - person FMaz008; 28.03.2011

arrow_upward
8
arrow_downward

Краткое обновление / дополнительная информация о предыдущем ответе: если вам не нравится подход git submodules или вы думаете, что это слишком сложно понять, вы можете попробовать

Не забудьте проверить, можете ли вы использовать другой менеджер зависимостей (например, RubyGems для Ruby, Composer для PHP...) вместо подмодулей, его будет проще использовать и поддерживать.

person Maxime Brehin    schedule 25.01.2016