Вендор Филиалы в Git
У проекта Git есть второй проект, содержание которого разрабатывается независимо.
Подмодули нельзя использовать для меньших, так как даже подпроект должен быть включен, когда пользователи пытаются клонировать или загрузить "родительский объект".
Объединение поддеревьев не может быть использовано, поскольку подпроект активно разрабатывается, а объединение поддеревьев затрудняет объединение этих обновлений обратно в исходный проект.
Мне сообщили, что решение известно в мире SVN как "Ветви поставщиков", и что оно так просто делается в Git, что даже не требует адресации. Полуготовые уроки в изобилии в сети.
Тем не менее, я не могу заставить его работать.
Может кто-нибудь, пожалуйста (довольно, пожалуйста?) Объяснить, как я могу создать структуру, при которой один проект существует в другом, и оба могут разрабатываться и обновляться из одного и того же рабочего каталога. В идеале [или скорее: очень важно, если не поддерживается], что, когда клиент пытается загрузить "родительский" проект, ему должна быть автоматически предоставлена последняя версия подпроекта.
Пожалуйста, НЕ объясняйте мне, как я должен использовать подмодули или слияния поддеревьев или даже SVN:Externals. Этот поток является результатом следующего SO потока, и если что-то там пропустили, пожалуйста, разместите его там. Эта ветка пытается получить представление о том, как продвигать ветки, и чем длиннее, яснее и более придумано объяснение, тем более счастливым я буду.
4 ответа
Я думаю, что субмодули - это путь, когда дело доходит до "ветки поставщиков".
Вот как вы должны использовать субмод... хммм, шучу.
Просто мысль; ты хочешь:
- разрабатывать как основной проект, так и подпроект в одном и том же каталоге (который называется "системный подход": вы разрабатываете, помечаете и объединяете всю систему)
- или для просмотра вашего подпроекта как "ветки поставщика" (которая является веткой, которая позволяет вам получить доступ к четко определенной версии внешнего компонента поставщика - или "набором файлов"), и которая обновляется только новыми версия каждого выпуска этого внешнего компонента: это называется "компонентный подход", вся система рассматривается как набор отдельных компонентов, разработанных самостоятельно)
Два подхода не совместимы:
- Первая стратегия совместима с объединением поддеревьев: вы работаете как над проектом, так и с подпроектом.
- Второй используется с подмодулями, но подмодули используются для определения конфигурации (список тегов, с которыми вам нужно работать): каждый подмодуль git, в отличие от svn:externals, прикрепляется к определенному идентификатору коммита, и это позволяет вам определить конфигурацию (как в SC M: "управление конфигурацией программного обеспечения")
Мне нравится второй подход, потому что большую часть времени, когда у вас есть проект и подпроект, их жизненный цикл отличается (они не разрабатываются в одном и том же ритме, не помечаются вместе в одно и то же время и не имеют одинакового имени),
Что действительно мешает этому подходу ("на основе компонентов") в вашем вопросе, так это то, что "оба могут быть разработаны и обновлены из одного рабочего каталога".
Я действительно призываю вас пересмотреть это требование, так как большинство IDE вполне способны работать с несколькими "исходными" каталогами, а разработка подпроекта может быть выполнена в его собственной специализированной среде.
Самгуди добавляет:
Представьте себе плагин eMap для Joomla и ModX. И плагин, и специфичный для Joomla код (который является частью Joomla, а не eMap) разрабатываются, пока плагин находится внутри Joomla. Все пути относительно, структура жесткая, и они должны быть распределены вместе - даже если у каждого проекта свой жизненный цикл.
Если я правильно понимаю, вы находитесь в конфигурации, в которой среда разработки (набор файлов, над которыми вы работаете) практически не отличается от среды распространения (тот же набор файлов копируется на платформу выпуска)
Все сводится к проблеме гранулярности:
- если оба набора файлов не могут существовать один без другого, тогда они должны рассматриваться как один большой проект (и объединенный с поддеревьями), но это вынуждает их помечать и объединять как один. -Если одно зависит от другого (которое может быть разработано отдельно), то они должны находиться в своем собственном Git-репозитории и проекте, первый из которых зависит от конкретного коммита второго, как субмодуль: если субмодуль определенные в правом поддереве первого компонента, все относительные пути соблюдаются.
Самгуди добавляет:
В оригинальном потоке перечислены проблемы с подмодулями - в первую очередь, из-за того, что загрузка GitHub не включает их (жизненно важно для меня) и что они застряли в определенном коммите.
Я не уверен, что загрузка GitHub недавно стала проблемой: в статье " Руководства: Разработка с помощью подмодулей" упоминается:
Лучше всего: люди клонируют ваши
my-awesome-frameworkвилка не будет иметь никаких проблем, потянув внизmy-fantastic-pluginсубмодуль, поскольку вы зарегистрировали общедоступный URL-адрес клона для субмодуля. Команды
$ gh submodule init
$ gh submodule update
Потянет подмодули в текущий репозиторий.
Что касается "они застряли на конкретном коммите": это все, что нужно для подмодуля, позволяющего вам работать с конфигурацией (списком теговых версий компонентов) вместо последнего потенциально нестабильного набора файлов.
Самгуди упоминает:
Мне нужно избегать как поддеревьев, так и подмодулей (см. Вопрос), и я бы предпочел решить эту проблему, не споря слишком много, если подход оправдан
Ваше требование совершенно законно, и я не хочу судить о его обоснованности: мои предыдущие ответы приведены только для того, чтобы предоставить более широкий контекст и попытаться проиллюстрировать варианты, обычно доступные с помощью универсального инструмента SCM.
Ответом должно быть слияние поддеревьев, но оно подразумевает объединение только коммитов, сделанных для файлов основного проекта, а не коммитов, сделанных для подпроектов. Если вы сможете управлять таким частичным слиянием, я бы сказал, что это правильный путь.
Я не вижу, однако, родного способа Git делать то, что вы хотите, который не использует subtree-merge или submodule.
Я надеюсь, что настоящий гит Git опубликует здесь более адекватный ответ.
Наконец у меня есть несколько часов доступа к сети, прежде чем я вернусь в горы. Посмотрим, смогу ли я внести ясность в вашу ситуацию.
Мое (возможно, слишком упрощенное) понимание состоит в том, что у вас есть (сторонние) поставщики, разрабатывающие плагины для вашего проекта, где ваша (внутренняя) команда разрабатывает код для вашего основного проекта с использованием среды из внешних источников. Поставщик не вносит изменений в ваш код и, вероятно, не нуждается в вашей передовой разработке, но ему нужен ваш стабильный код для разработки и тестирования своей работы. Ваша команда не вносит изменения в платформу, но иногда вносит изменения в плагин.
Как и VonC (который обычно все продумывает очень тщательно), я не думаю, что Git идеально подходит для ваших требований. И, как и он, я думаю, что использование шаблона слияния поддеревьев является наиболее подходящим вариантом. Я не гуру Git, но мне удалось согнуть Git для широкого спектра потребностей. Возможно, Git не соответствует вашим потребностям:
SVN позволит вам иметь несколько репо в одном, что кажется важным для вас. Я думаю, что это будет означать либо использование внешних элементов, либо паттерн Vendor Branch, чтобы приблизиться к тому, что вы хотите.
У Mercurial есть расширение Forest для использования вложенных репозиториев, которое, похоже, лучше подходит для вашей ментальной модели. Я выбрал Git вместо Mercurial 15 месяцев назад, но HG был стабильным и, по-моему, для многих применений сравним с Git. Я не знаю, насколько стабильно расширение.
Если бы я был в вашей ситуации, я бы использовал два репозитория Git - одно для плагина и одно для MainProject. Поставщик будет заниматься разработкой в репозитории плагинов и будет иметь ветку релизов, в которую они будут загружать текущие версии плагина без остальной среды разработки. Эта ветвь будет включена в репозиторий MainProject как ветка поставщика, а затем объединена с вашей основной веткой разработки. Когда ваша команда работает над изменением плагина, они разрабатывают его в функциональной ветви основной ветки разработки и отправляют в репозиторий поставщика в виде исправлений. Это дает вам очень чистый рабочий процесс, относительно простой в настройке и изучении, сохраняя при этом историю разработки отдельно.
Я не пытаюсь спорить, но просто хочу сказать, что Git лучше всего подходит для моего понимания вашей ситуации. Самый простой способ настроить это - использовать объединение поддеревьев, но это не приводит к изменениям через него в обоих направлениях, что было моим возражением против использования этого шаблона.
Если ваша команда действительно активно участвует в разработке плагинов или вы действительно хотите, чтобы история разработки как проекта, так и плагина была интегрирована в одно Git-репо, просто используйте одно Git-репо. Вы можете извлекать плагин и его историю для записей вашего поставщика, как описано здесь, время от времени. Это может дать вам меньше инкапсуляции, чем вы предполагали, но Git не предназначен для инкапсуляции - структура данных Git основана на отслеживании изменений в рамках одного целого проекта.
Может быть, я неправильно понял вашу ситуацию, и ничего из этого не применимо. Если так, я прошу прощения. Спасибо за детали, которые вы и VonC проработали, которые заполнили многие дыры, которые у меня изначально были при попытке понять ваш вопрос.
Если вы ищете только название оригинального вопроса:
хороший шаблон для ветки вендора с git включен
https://www.roe.ch/Git_Reference
раздел Vendor филиал шаблон
Слияние поддеревьев использовать нельзя, так как подпроект активно развивается, а слияние поддеревьев очень затрудняет слияние этих обновлений обратно в исходный проект.
Исходный вопрос (от 20 апреля 2009 г.) предшествует объявлению поддерева git всего на 10 дней. Трудно точно сказать, что искал ОП, но это может быть правильным ответом.
Обратите внимание, что это инструмент командной строки. В настоящее время он входит в состав git. Он использует слияние поддеревьев, но это не одно и то же. Оно имеетgit subtree pushкоманда, предназначенная для объединения ваших локальных изменений обратно в вышестоящий подпроект.
Мне сообщили, что это решение известно в мире SVN как «ветки поставщика» и что оно настолько просто делается в Git, что даже не требует адресации. Полусырые учебники изобилуют в сети.
Я написал https://david.rothlis.net/vendor-branch/ , чтобы объяснить ветки поставщиков в git и то, как они связаны сgit subtree.