Альтернативы субмодулям Git?

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

• Есть ли другие инструменты для проектов с несколькими репозиториями и как они сравниваются?
• Могут ли эти инструменты работать в Windows?

Что лучше всего для вас, зависит от ваших потребностей, желаний и рабочего процесса. В каком-то смысле они полуизоморфны, просто некоторые из них намного проще использовать, чем другие, для конкретных задач.

• gitslave полезен, когда вы контролируете и разрабатываете подпроекты в более или менее то же время, что и суперпроект, и, более того, когда вы обычно хотите пометить, разветвить, нажать, тянуть и т. д. все репозитории одновременно. gitslave никогда не тестировался на окнах, о которых я знаю. Требуется perl.

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

• git-subtree предоставляет интерфейс для встроенной в git стратегии слияния поддеревьев. Лучше, если вы предпочитаете иметь "унифицированную" историю git для одного репозитория. В отличие от стратегии слияния поддеревьев, легче экспортировать изменения в разные деревья (директории) обратно в исходный проект, но это не так автоматично, как с gitslave или даже git-submodule.

• Репо теоретически похоже на gitslave, но не так хорошо документировано для операций, отличных от Android, которые я обнаружил. Он в значительной степени посвящен модели разработки Google Android и изначально поддерживает только несколько команд git (хотя вы можете запускать произвольные команды), а ограниченная встроенная поддержка не поддерживает, например, централизованный репозиторий для отправки и проверки ветка кажется довольно сложной.

• Kitenet mr - это то, что вы хотели бы использовать, если у вас есть несколько систем управления версиями, но в основном он ограничен для суперпроектов только с git из-за подхода с наименьшим общим знаменателем. Есть способы запускать произвольные команды, но они не так хорошо интегрированы.

Новое дополнение к списку альтернатив - Git X-Modules . Это сделано для того, чтобы избежать типичных недостатков подмодулей Git, описанных здесь . Основное отличие состоит в том, что вся синхронизация выполняется на стороне сервера, поэтому для конечных пользователей есть только обычный репозиторий Git, который они клонируют и отправляют.

В настоящее время я использую подмодули для разработки, а не только для связи сторонних библиотек. Есть несколько способов облегчить жизнь с помощью подмодулей, особенно когда они являются источником конфликтов слияния или перебазирования. Посмотрите на ls-tree, чтобы задействовать 2 коммита в конфликте в подмодуле. Это, наверное, самая сложная часть подмодулей для людей. На данный момент сценарии значительно упростят работу с этим. В будущих версиях Git должна быть улучшена встроенная поддержка для работы с ними.

Надеюсь это поможет.

Мы столкнулись с аналогичной проблемой при использовании подмодулей Git в проектах, где у нас были зависимости на разных языках. Чтобы справиться с ними, мы создали и открыли исходный код инструмента под названием MDLR («Модульный»), который предоставляет вам декларативные зависимости Git с управлением версиями с функциональностью, аналогичной подмодулям Git, но без раздражающего рабочего процесса. Вы можете установить его и управлять своими зависимостями с помощью инструкций / загрузок в репозитории GitHub

В некоторых случаях мне понравился каждый из следующих двух простых подходов:

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

• Репозитории пакетов. Для программных проектов, в которых вы используете какую-либо систему управления пакетами исходного кода (gem / bundler, npm, pear и т. Д.), Может иметь смысл поместить повторно используемый код в отдельные репозитории git, а затем сделать из них исходные пакеты, а затем установить их с помощью инструмента управления пакетами в родительский проект. Репозиторий git вашего родительского проекта будет содержать только ссылку на необходимые пакеты и их версии, в то время как фактический код этих пакетов будет игнорироваться git, как и все остальные пакеты и внешние библиотеки. По сравнению с предложенными выше вложенными репозиториями это более сложный подход, поскольку он позволяет указать, какая версия пакета должна быть установлена.