Pull to refresh

Comments 26

А не могли бы Вы сравнить возможности данного расширения с git subtree? Заранее спасибо.
Обязательно. Я сейчас работаю над описанием внутренностей git-subtree и скоро выдам раезультат.

Я сейчас исследую возможности git'а для построения сложных проектов.
Пока что осилил submodules. Они достаточно удобны, когда не нужно напрямую менять содержимое субмодулей. А ещё они нативной поддерживаются средствами сборки кода — gitlab-ci & co.
Интересно узнать альтернативные подходы, но чтобы удовлетворить это требование + чтобы было этими подходами удобно

Пользуемся сабмодулями достаточно активно для общих подпроектов сервисов. Всё можно менять и из основного репозитория. Точнее для работы с гитом сабмодуля — входишь в него и делаешь всё как и везде. Даже VSCode поддерживает работу с сабмодулями
В чём преимущество перед сабмодулями?
Дело не в преимуществе, а в целесообразности. Главное отличие состоит в том, что при использовании submodules, пользователь снимает репозиторий-контейнер практически не настроенным и ему надо проделывать дополнительные мероприятия по согласованию ревизий подмодулей и репозитория-контейнера (так или иначе, это именно так, и автор проекта должен обеспечить пользователя соответствующими инструкциями, будь то простая инструкция по клонированию `git clone --recurse-submodules ...' или другое напоминание). Если же мы говорим о git-subrepo и git-subtree, то здесь, копируя репозиторий-контейнер, пользователь получает полностью настроенное дерево за одну операцию git-clone(1). Все для него уже сделано автором. А в остальном, все зависит от задач, которые решает автор и от его политики SCM (Source Configuration Management).
Т.е. правильно ли я понимаю, что раз тут все проделывается за одну команду git-clone, то интеграция с системами сборки получается прозрачная и автоматическая?
Так точно. Автор должен все сделать так, чтобы для пользователя репозиторй выглядел как монолитная структура, не требующая дополнительных настроек.
Представим, например, следующую задачу. Ваш проект состоит из нескольких подпроектов/модулей и, допустим, один модуль представляет исходный код межмодульных интерфейсов. Набор интерфейсов, разрабатываемый отдельной командой, должен быть фиксирован для каждой ветки вашего проекта. Более того, никто из других команд разработчиков не должен иметь права изменять код интерфейсов, а наоборот, совершенствовать свой модуль в строгой согласованности с другими.

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

Согласитесь, что при данном подходе интерфейсный модуль лучше всего подключать не как submodule, обвязывая его хуками, а как subtree (а вот нужна ли при этом история интерфейсного модуля в общем индексе, это уже другой вопрос).
Ну фиг знает. Всё таки надёжнее каждый модуль проекта хранить в отдельной репе с полноценной историей. В основном проекте создаём папочку subreps, добавляем её в gitignore, в subreps клоним полноценные репы.
Вот только что делать при таком подходе, если у вас несколько веток в проекте и к каждой отдельной ветке нужно подцеплять «свою» ветку из другого проекта. git subtree эту проблему решает на раз. Единственное неудобство — merge между своими ветками нужно делать осторожно, чтобы подпроекты не смержились.
А какая разница сколько веток и какой проект? Это ж полноценные репы, цепляйте что хотите.
Вы предлагаете после смены ветки в своем проекте еще ручками менять ветки в «подпроектах»?
Ну не руками это делать в каждой репе конечно же :) Это легко автоматизируется скриптом.

git submodule update — это слишком сложно? :)

Я отвечал calg0n, который submodule не использует. См.выше.
В проекте, над которым я работаю, мы используем submodule и каждая ветка основного проекта связана с конкретной веткой сабмодуля. Меняю ветку — сабмодуль тоже меняется, что я делаю не так?
Это если один проект. А если несколько проектов используют общий функционал? Если у каждого проекта своя репа и этот общий функционал нужно использовать в них. Сабмодули тут не подойдут.
Есть как минимум ещё один проект, где используется тот же самый сабмодуль.
А как вы разруливаете конфликты когда несколько разрабов работают над общей репой?
Как обычно, не вижу разницы, если честно. Фичи делаются в отдельных ветках, перед merge делаем rebase чтобы свести конфликты к минимуму, если какие-то ломающие изменения — то да, всем придётся править код, но только после принудительного обновления сабмодуля до мастера (т. е. ничего не ломается само по себе).
Насколько я знаю подмодули не работают без корневого репозитория, ветки наследуются от родителя и сабмодули не хранят историю изменений файлов, только хеш-сумму этих изменений. Из-за этого есть проблемы с мержем подмодулей в рамках проекта.
Возможно что-то изменилось с того момента, но насколько я вижу — нет.
Ну как, у нас сабмодуль — это полноценный репозиторий. В том плане, что если изменения в проекте требуют изменений в сабмодуле — делается отдельная ветка и там и там, два пулл реквеста и т. д. За счёт линейной истории конфликты сведены к минимуму. Грубо говоря, для проекта сабмодуль — это внешний компонент, и конфликт сводится к тому, что есть хэш, в котором реализована фича А, и есть хэш, в котором она не реализована, ничего сложного.
Проблемы с мержем сабмодулей, про которые вы говорите, за полтора года работы над этим проектом встречались раза два.
Мы постоянно сталкиваемся с конфликтами в своей общей репе :) Тут зависит от проекта конечно же, но с т.з. полноценного подрепозитория сабмодули нам не подошли.
git-subrepo и git-subtree не отменяет возможность ведения upstream-репозиториев как самостоятельных продуктов, а в основном дереве держать либо squashed-комиты, либо полноценные истории.

А на счет папочек в .gitignore все зависит от CM инженера. Либо он настраивает права пользователей и хуки, либо он отдает все на откуп инженерам команды разработчиков.

Товарищ Сухов сказал: «Лучше конечно помучиться.»
Sign up to leave a comment.

Articles