Я думаю, что субмодули - это путь, когда дело доходит до «ветки поставщиков».
Вот как вы должны использовать субмод ... хммм, шучу.
Просто мысль; Вы хотите:
- для разработки как основного проекта, так и подпроекта в одном и том же каталоге (который называется " системный подход ": вы разрабатываете, маркируете и объединяете всю систему)
- или для просмотра вашего подпроекта как «ветки поставщика» (которая является веткой, которая позволяет получить доступ к четко определенной версии внешнего компонента поставщика - или «набором файлов»), и которая только обновляется с новой версией каждого выпуска этого внешнего компонента: который называется « компонентный подход », вся система рассматривается как набор отдельных компонентов, разработанных самостоятельно)
Два подхода не совместимы:
- Первая стратегия совместима с объединением поддеревьев: вы работаете как над проектом, так и с подпроектом.
- Второй используется с подмодулями, но подмодули используются для определения конфигурации (список тегов, с которыми вам нужно работать): каждый подмодуль git, в отличие от svn: externals, прикрепляется к определенному коммиту id, и это то, что позволяет вам определить конфигурацию (как в S C M: «программное обеспечение конфигурация управление»)
Мне нравится второй подход, потому что большую часть времени, когда у вас есть проект и подпроект, их жизненный цикл отличается (они не разрабатываются в одном и том же ритме, не помечаются вместе на в то же время, ни с тем же именем).
Что действительно мешает этому подходу («на основе компонентов») в вашем вопросе, так это то, что «оба могут быть разработаны и обновлены из одного рабочего каталога».
Я действительно призываю вас пересмотреть это требование, так как большинство IDE вполне способны работать с несколькими «исходными» каталогами, а разработка подпроекта может быть выполнена в его собственной выделенной среде.
samgoody добавляет:
Представьте себе плагин eMap для Joomla и ModX. И плагин, и специфичный для Joomla код (который является частью Joomla, а не eMap) разрабатываются, пока плагин находится внутри Joomla. Все пути относительно, структура жесткая, и они должны быть распределены вместе - даже если у каждого проекта свой жизненный цикл.
Если я правильно понимаю, вы находитесь в конфигурации, в которой среда разработки (набор файлов, над которыми вы работаете) практически не отличается от среды распространения (тот же набор файлов копируется на платформу выпуска)
Все сводится к проблеме гранулярности:
- если оба набора файлов не могут существовать один без другого, то их следует рассматривать как один большой проект (и объединенный в поддерево), но это заставляет их помечать и объединять как один.
-Если одно зависит от другого (которое может быть разработано отдельно), то они должны находиться в своем собственном Git-репозитории и проекте, причем первый зависит от конкретного коммита второго, как субмодуль: если субмодуль определяется в правом поддереве первого компонента, все относительные пути соблюдаются.
samgoody добавляет:
В оригинальном потоке перечислены проблемы с подмодулями - в первую очередь из-за того, что загрузка GitHub не включает их (жизненно важно для меня) и что они застряли при конкретном коммите.
Я не уверен, что загрузка GitHub недавно стала проблемой: в статье " Руководства: Разработка с подмодулями " упоминается:
Лучше всего: у людей, клонирующих ваш my-awesome-framework форк, не возникнет проблем при сбрасывании вашего подмодуля my-fantastic-plugin, поскольку вы зарегистрировали общедоступный URL-адрес клона для этого подмодуля. Команды
$ gh submodule init
$ gh submodule update
Перетянет подмодули в текущий репозиторий.
Что касается «они застряли на определенном коммите»: это основная точка подмодуля, позволяющая вам работать с конфигурацией (список теговых версий компонентов) вместо самой последней потенциально нестабильный набор файлов.
samgoody упоминает:
Мне нужно избегать как поддеревьев, так и подмодулей (см. Вопрос), и я бы скорее удовлетворил эту потребность, не слишком споря, если подход оправдан
Ваше требование является совершенно законным, и я не хочу судить о его обоснованности: мои предыдущие ответы приведены только здесь, чтобы предоставить более широкий контекст и попытаться проиллюстрировать варианты, обычно доступные с помощью общего инструмента SCM.
Слияние поддерево должно быть ответом здесь, но подразумевало бы объединение только коммитов, сделанных для файлов для основного проекта, а не коммитов, сделанных для подпроектов. Если вам удастся справиться с таким частичным слиянием, я считаю, что это верный путь.
Я не вижу, однако, родного способа Git делать то, что вы хотите, который не использует слияние поддеревьев или субмодуль.
Я надеюсь, что настоящий гит Git опубликует здесь более адекватный ответ.