Филиалы поставщиков в Git

Ответ 1

Я думаю, что подмодули - это путь, когда дело доходит до "ветки поставщика".
Вот как вы должны использовать подмод... хммм, просто шутите.

Просто мысль; вы хотите:

• для разработки основного проекта и подпроекта в рамках одного и того же каталога (который называется системным подходом ": вы разрабатываете, тегируете и объединяете всю систему)
• или просмотреть ваш подпроект как "ветвь поставщика" (которая является ветвью, которая позволяет вам получить доступ к хорошо определенной версии внешнего компонента поставщика - или "набор файлов" - и которая обновляется только с новой версией каждого выпуска этого внешнего компонента: который называется " компонентным подходом", вся система рассматривается как совокупность отдельных компонентов, разработанных сами по себе).

Два подхода несовместимы:

• Первая стратегия совместима с поддеревом-слиянием: вы работаете как над проектом, так и подпроектом.
• Второй используется с подмодулями, но подмодули используются для определения конфигурации (список тегов, которые вам нужны для работы): каждый подмодуль git, в отличие от svn: externals, привязан к конкретный идентификатор фиксации, и именно это позволяет вам определить конфигурацию (как в SCM: "управление конфигурацией программного обеспечения" ).

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

Что действительно мешает этому подходу ( "на основе компонентов" ) в вашем вопросе "часть, которую можно развить и обновить из той же самой рабочей директории". Я бы настоятельно рекомендовал вам пересмотреть это требование, так как большинство IDE отлично справляются с несколькими "источниками" каталогов, а разработка подпроектов может быть выполнена в собственной специализированной среде.

samgoody добавляет:

Представьте себе плагин eMap для Joomla и ModX. Как плагин, так и код Joomla (который является частью Joomla, а не eMap) разрабатываются, когда плагин находится внутри Joomla. Все пути относительны, структура жесткая, и они должны распределяться вместе - хотя каждый проект имеет свой жизненный цикл.

Если я правильно понимаю, вы находитесь в конфигурации, в которой среда разработки (набор файлов, на которых вы работаете), совсем не похожа на среду распространения (тот же набор файлов скопирован на платформе выпуска)

Все происходит с проблемой детализации:

• Если оба набора файлов не могут существовать один без другого, тогда их следует рассматривать как один большой проект (и с поддеревом), но это заставляет их быть помечены и объединены как один. если каждый из них зависит от другого (который может быть разработан отдельно), то они должны быть в своем собственном репозитории и проекте git, первый из которых зависит от конкретной фиксации второго в качестве подмодуля: модуль определяется в правом поддереве первого компонента, все относительные пути соблюдаются.

samgoody добавляет:

В исходной теме перечислены проблемы с подмодулями - прежде всего, что загрузка GitHub не включает их (жизненно важные для меня) и что они застревают в определенном коммите.

Я не уверен, что загрузка GitHub недавно была проблемой: " Guides: Developing with Submodules" в статье упоминается:

Лучше всего: у людей, клонирующих вашу вилку my-awesome-framework, не будет проблем с выводом вашего подмодуля my-fantastic-plugin, так как вы зарегистрировали публичный URL-адрес клонирования для подмодуля. Команды

$ gh submodule init
$ gh submodule update

Потянет подмодули в текущий репозиторий.

Что касается "они застревают в определенном коммите": это все точки подмодуля, позволяющие вам работать с конфигурацией (список помеченной версии компонентов) вместо последнего потенциально неустойчивого набора файлов.

samgoody упоминает:

Мне нужно избегать как поддеревьев, так и подмодулей (см. вопрос), и скорее рассмотрит эту потребность, не слишком сильно рассуждая, если подход оправдан.

Ваше требование является совершенно законным, и я не хочу судить о его оправдании: мои предыдущие ответы только здесь, чтобы обеспечить больший контекст и попытаться проиллюстрировать варианты, обычно доступные с помощью общего инструмента SCM.

Слияние должно быть ответом здесь, но подразумевает слияние только коммитов, сделанных для файлов для основного проекта, а не коммитов, сделанных для подпроектов. Если вы можете справиться с таким частичным слиянием, я бы считал, что это правильный путь.

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

Ответ 2

У меня, наконец, есть несколько часов доступа к сети, прежде чем я вернусь в горы. Мы посмотрим, есть ли у меня что-нибудь, чтобы внести ясность в вашу ситуацию.

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

• Как и VonC (который, как правило, очень хорошо разбирается в вещах), я не думаю, что Git идеально подходит для ваших требований. И, как и он, я думаю, что использование шаблона слияния поддерева является самым близким. Я не гуру Git, но мне удалось сгибать Git для широкого круга потребностей. Возможно, Git не отвечает вашим потребностям:

  • SVN позволит вам иметь несколько репозиций в одном, что кажется важным для вас. Я думаю, что это будет означать либо использование внешних, либо шаблонов Branch Vendor, чтобы приблизиться к тому, что вы хотите.

  • Mercurial имеет расширение, Лес, для используя вложенные репозитории, которые, по-видимому, лучше подходят для вашей ментальной модели. Я выбрал Git над Mercurial 15 месяцев назад, но HG был стабильным, и для многих применений я думаю, что он сравним с Git. Я не знаю, насколько стабильным является расширение.

• Если бы я был в вашей ситуации, я бы использовал два Git repos - один для плагина и один для MainProject. Поставщик будет делать разработку в репозитории Plugin и будет иметь ветвь релиза, чтобы они вытягивали текущие версии плагина без остальной среды разработки. Эта ветвь будет втягиваться в репозиторий MainProject как ветвь поставщика, а затем объединяться в вашу основную ветвь развития. Когда ваша команда работает над изменением подключаемого модуля, они развивают его в филиале функции вашей основной ветки развития и отправляют его репозиторию поставщика в виде патчей. Это дает вам очень чистый рабочий процесс, относительно прост в настройке и учебе, сохраняя при этом историю развития отдельно.

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

• Если ваша команда действительно активно участвует в разработке плагинов или вы действительно хотите, чтобы история разработки как проекта, так и подключаемого модуля была интегрирована в один репозиторий Git, просто используйте один репозиторий Git. Время от времени вы можете извлекать подключаемый модуль и его историю для записей вашего поставщика как здесь. Это может дать вам меньше инкапсуляции, чем вы предполагаете, но Git не предназначен для инкапсуляции. Git структура данных основана на отслеживании изменений внутри одного целого проекта.

Возможно, я неправильно понял вашу ситуацию, и ничто из этого не применимо. Если так, то я приношу свои извинения. Спасибо за детали, которые вы и VonC разработали, которые заполнили множество отверстий, которые я изначально пытался понять ваш вопрос.