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

83

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

  • Есть ли другие инструменты для проектов с несколькими репозиториями и как они сравниваются?
  • Могут ли эти инструменты работать в Windows?
Чау Чи Ян
источник
3
Вы говорите о стратегии слияния поддерева Git или git-subtree Эйвери Пеннаруна ? По сути, это не одно и то же.
kynan
1
Хорошо читайте здесь codingkilledthecat.wordpress.com/2012/04/28/…
nawfal
3
См. Мой неофициальный форк gitslave , который , надеюсь, более активен, чем оригинал, начиная с 2.0.2.
Joel Purra
1
Также существует git-subrepo .
huggie

Ответы:

101

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

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

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

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

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

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

Сет Робертсон
источник
7
Обратите внимание, что git-subtree в этом ответе относится (как уже упоминалось) к стратегии слияния поддеревьев Git, а не git-subtree Эйвери Пеннаруна , которые принципиально не совпадают. Последний был специально разработан, чтобы позволить вносить изменения обратно из поддерева.
kynan
3
Отличная поломка! Я бы хотел, чтобы в него были внесены поправки, чтобы отличать «слияние поддерева» от git-subtree, как упоминает @kynan.
BrianTheLion
1
@Tobu: Я не считаю способность мистера запускать произвольные команды такой же, как наличие встроенной поддержки команд git. Я предполагаю, что здесь вы говорите о чем-то вроде mr run git config ...или, возможно (даже хуже) о методе файла конфигурации для присвоения имен конкретным командам. Конечно, если вы знаете о некоторых функциональных возможностях mr, которые не сразу были очевидны при чтении страницы руководства, я хотел бы знать об этом.
Сет Робертсон
4
@kynan: в дополнение к вашему комментарию. Я хотел бы отметить, что git-subtree Avery Pennarun теперь доступен в git 1.7.11 и выше.
slatunje
1
@sealTrip: доступно как в git/contrib. Установить в Ubuntu sudo make install install-doc prefix=/usr libexecdir=/usr/lib/git-coreиз дерева исходных текстов Git ( не работает с упакованным Git).
kynan
2

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

Дмитрий Линов
источник
1

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

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

Адам Димитрук
источник
0

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

сварламов
источник
Эта проблема выглядит
некорректно
0

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

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

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

Таниус
источник