Что лучше использовать для мультимодульного проекта: subtree или submodule?

Question

[Владимир Семенякин]

Пишу мультимодульный проект на С++. До этого вставлял исходный код модулей-зависимостей прямо в исходный код модуля, для которого описывались эти зависимости (копа-паста, лень было заморачиваться с гитовскими приколами для этого). Недавно понял, что такое не катит и нужно организовать всё по-человечески, через какой-нибудь предоставляемый гитом механизм.

Почитал про submodules, но потом наткнулся на эту статью и на эту статью. Там говорилось что есть такая штука - subtree - которая намного круче чем submodules. Почитал, и возникло подозрение, что не совсем корректно сравнивать эти механизмы, у них просто разные области применения.

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

Путанные соображения по поводу

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

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

Исходя из этого, как я понимаю, механизм submodule был рассчитан на использование в проектах, для которых переход на новую версию зависимости означает серьёзные изменения в самом проекте (например, новая версия меняет программный интерфейс, что может привести к поломке компилирования кода проекта). В контексте изоляция зависимости от pull-а внешнего проекта для submodule это не баг, а фич - фича, позволяющая более строго контролировать версии зависимостей на машинах всех коммитеров проекта. Другой вопрос, конечно, почему нельзя при каждом пуле внешнего проекта автоматически смотреть не пришло ли обновление версии зависимости в рамках заданной в .gitsubmodule - но это отдельная тема.

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

updated: Продолжение обсуждения

Comments

[Сергей Наломенко]

Благодаря Вашему вопросу открыл для себя наличие возможности вставлять в вопросы спойлеры :)

Answer 1

[Andy_U]

В первой из процитированных вами статей (от 2009 гю) говорится не о git subtree, а о subtree merge strategy. Вторая - правильная. Единственно, чего не делаю, так это не определяю subtree как remote, чтобы во всяких Git Extension лишних "хвостов" от подпроектов не повисало.

Далее, поскольку любое обновление подпроекта через subtree pull делается ручками, а не автоматически, то вашего последнего утверждения я не понимаю. Вот сделал наконец разработчик новую версию своего модуля (длинной серий коммитов), потом в основном проекте сделал новую ветку, туда сделал pull своих окончательных изменений, проверил, что все работает, и может мержить в основную ветку. Или какой там у вас workflow? А разработчикам основного модуля и знать о subtree не надо. Вот есть поддиректория с (изменившимся) плагином - вот и пользуйтесь. Есть проблемы - обсуждайте с его разработчиком.

P.S. И почитайте про "грабли" с submodule - по ссылке во второй статье...
Написано только что

Comments

[Владимир Семенякин]

Я что-то запутался. Давайте разберёмся по картинке. Вот есть три репозитория. Один из них (третий, our repo) это наш репозиторий. В какой-то момент мы решили привязать к нему модуль, у которого есть свой репозиторий (второй репозиторий, module repo). В коммите, который обозначен маркером (1) мы выполнили его связывание с нашим (пока опустим конкретный способ связывания - subtree или submodule). При существует другой проект (первый, other repo, и такой проект может быть не один), который также использует модуль. При этом что наш проект, что сторонний может в течение разных промежутков времени "сидеть" на определённой версии модуля, и обновляться в нужные для этих проектов моменты времени (коммиты, выполняющие изменение версии зависимости: маркеры (3) и (4) ).

Картинка

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

Для submodule:
- Использование в ситуации, когда module repo не находится в нашем прямом распоряжении, это сторонний репозиторий, разрабатываемый другой конторой/командой разработчиков. В этом случае нам всё равно какие изменения происходят в этом модуле, нас интересуют вполне конкретные версии этого репо. Мы не хотим чтобы новые снапшоты модуля мусорили историю нашего репозитория - это сторонний, скорее всего законченный проект вне нашей области ответственности, который мы не трогаем - максимум пул-реквесты владельцам репо с пожеланиями наших изменений.

Для subtree:
- Использование для разработки внутри конторы. Какие-то внутренние модули или даже просто шареные файлы, единые для нескольких внутренних проектов, которые можно обсудить с человеком за стенкой (то, что вы описали как "есть проблемы - обсуждайте с разработчиком").
- Использование для open source, где происходит активная разработка большой командой людей. В этом смысле subtree выступает чем-то вроде обычной ветки, но расшаренной между несколькими репозиториями для удобства.

Ясно что в обоих случаях перед переходом на новую версию моделя в основном проекте (superpoject) будет уход в ветку для внесения изменений в связи с переходом. Но тут речь идёт, скорее, об идеологии использования.

П.С.: Сегодня читал документацию, и там написано что-то, как мне показалось, намекающее на подобное разграничение областей использования subtree и submodule.

Цитата

If you want to merge the project histories and want to treat the aggregated whole as a single project from then on, you may want to add a remote for the other project and use the subtree merge strategy, instead of treating the other project as a submodule. Directories that come from both projects can be cloned and checked out as a whole if you choose to go that route

[Andy_U]

Вот тот вариант использования, который будто бы для submodule - он прекрасно работает и для subtree. Вы можете скачать себе чужой проект в состоянии, определенном (вами) каким-либо произвольным коммитом. Не обязательно последнюю версию в master-ветке. И пока вы снова git subtree pull не сделаете, ничего в вашем проекте не поменяется.

[Владимир Семенякин]

Andy_U: тогда не совсем понятно зачем авторы git оставляют оба механизма. Обратная совместимость?

[Andy_U]

Вы знали :)

[Владимир Семенякин]

Andy_U: ясно. Спасибо за ответ

[Владимир Семенякин]

Andy_U: а вы не встречали официальной информации от авторов git, которая говорила бы о механизме submodule как об устаревшем? Я попробовал поискать только что - не вышло найти, только несколько ругательных статей, рассказывающих почему submodule такая неудобная штука.

[Andy_U]

Нет, я год назад выбрал для себя subtree и с тех пор просто пользуюсь. И, конечно, решение не 100% идеальное - подпроект подтягивается целиком, со всеми тестами, документацией и пр., и не в ту поддиректорию, где бы я хотел видеть питоновский пакет, но лучшего варианта я пока не нашел.

[Владимир Семенякин]

Andy_U: продолжаю изучать вопрос. Вот ещё симптомотичная статья, как по мне. Была написана в 2013-ом году. В самой статье автор жутко ругает submodule. Его вывод: "Now, I think that is [subtree] much better than using submodules and a lot less invasive to my repo."

Статья интересна развитием истории в обсуждениях. subtree некоторые, ругают (1 феврая 2013), некоторые хвалят (упоминается Pro Git book, их которой, по словам автора, следует что subtree выглядит лучше, коммент от второго февраля 2013 года).

Через полгода автор статьи отвечает (26 августа 2013 года) на вопрос по поводу subtree: да, спустя полгода он по-прежнему любит subtree.

Дальше самое странное. Продолжение обсуждения, март 2015 года, упоминание subtree как деприкейтнутой технологии и комментарий по-прежнему ругательный по отношение к submodule: "I understand subtrees were deprecated in favor of submodules, but I still feel that submodules have various drawbacks"

Кстати, выше, ещё один комментарий: "After all, subtree merge was invented merely as a short-term hack to serve as a stop gap measure until submodule support becomes mature". То есть subtree была придумана как хак.

Наконец, последний комментарий в обсуждении, середина октября 2015 года. Subtree по-прежнему круче по мнению комментатора: "OTOH submodules are very brittle, so I'm reluctant to use them as well".

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

Но при этом механизм subtree, судя по всему, был временным решением, которое оказалось круче основного.

П.С.: Самое интересное, по subtree таки действительно нет статьи в официальной доке (git subtree help не проходит в моей версии гита). Вот одна из первых ссылок в гугл по запосу git subtree documentation, и это не та дока, что для всех прочих команд в svn - это просто отдельный от хэлп по теме как можно использовать subtree в проектах.

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

[Andy_U]

Вам шашечки или ехать? :)

[Владимир Семенякин]

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

[Владимир Семенякин]

Andy_U: но понял, что буду, скорее всего, subtree использовать - не смотря на то, что submodule (насколько я успел его понять) мне кажется более правильным идеологически для конкретно моего случая; всё испортили комментарии по поводу ужасов бранчевания при использовании submodule.

[Владимир Семенякин]

Вообще великолепно. Смотрю уже следующий вопрос - изоляция части проекта в отдельную репу, чтобы дальше subtree на части его побить, и натыкаюсь на комментарий (edited Aug 28 '14 at 19:51) с пометкой в updated-секци:

"This process is so common, that the git team made it much simpler with a new tool, git subtree"

New, блин, tool, понимаете ли...

Answer 2

[Владимир Семенякин]

Ещё одно мнение. Совпадает с моим взглядом на вещи - submodule для работы в репо вне нашей области ответственности, subtree - для двунаправленного взаимодействия.

update: Ещё одно обсуждение по теме.

Answer 3

[Алексей Киселев]

Лучше воспользоваться системой управления зависимостями. Например Apache Ivy или аналогичной. Считается, что subtree и тем более submodule являются упрощенными и ограниченными по функциональности заменами нормальных систем управления зависимостями. Вот неплохое описание проблем связанных с использовани....
Использование Ivy подразумевает наличие системы сборки проекта. Но возможности по управлению зависимостями открываются неограниченные. Особенно приятно когда у вас команда из больше чем 2-3 человек, 2-3 десятка библиотек и нужно поддерживать и развивать несколько версий приложения одновременно.
Хотя Ivy написана на Java и очень тесно интегрирована в мир Java, она является универсальным менеджером зависимостей и мы использовали ее для управления зависимостями в проекте на C#.
Возможно, для C++ есто что-то свое, но я далек от этого мира.

Comments

[Владимир Семенякин]

Не поверите - я как раз пытаюсь написать свою систему решения зависимостей (обобщённую, с интегрированной в неё системой контроля версий ресурсов для сборки и билд-системой). Вопрос задавал как раз для приведения в порядок этого проекта.

Возможно, для C++ есто что-то свое, но я далек от этого мира

В С++ нет модулей, поэтому там труднее с этим. В плюсах есть темплейты, что делает работу с зависимостями ещё труднее. Из того, что есть и что я немного пробовал - есть biicode, который работает на уровне исходников - читает иклуды и грузит файлы по соответствующим путям в глобальном репозитории. Подход, кстати, весьма неплох в своей простоте - отчасти его себе притырил.

П.С.: Спасибо за указание на Ivy - судя по всему, штука близкая к тому, что я делаю. Почитаю и, возможно, даже для себя использую.