@semenyakinVS
Писатель кода и не только

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

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

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

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

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

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

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

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


updated: Продолжение обсуждения
  • Вопрос задан
  • 2321 просмотр
Решения вопроса 1
@Andy_U
В первой из процитированных вами статей (от 2009 гю) говорится не о git subtree, а о subtree merge strategy. Вторая - правильная. Единственно, чего не делаю, так это не определяю subtree как remote, чтобы во всяких Git Extension лишних "хвостов" от подпроектов не повисало.

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

P.S. И почитайте про "грабли" с submodule - по ссылке во второй статье...
Написано только что
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
@semenyakinVS Автор вопроса
Писатель кода и не только
Ещё одно мнение. Совпадает с моим взглядом на вещи - submodule для работы в репо вне нашей области ответственности, subtree - для двунаправленного взаимодействия.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы