Comments 26
А не могли бы Вы сравнить возможности данного расширения с git subtree? Заранее спасибо.
+2
Обязательно. Я сейчас работаю над описанием внутренностей git-subtree и скоро выдам раезультат.
+1
Опубликовал статью о git-subtree habr.com/post/429014
0
Я сейчас исследую возможности git'а для построения сложных проектов.
Пока что осилил submodules. Они достаточно удобны, когда не нужно напрямую менять содержимое субмодулей. А ещё они нативной поддерживаются средствами сборки кода — gitlab-ci & co.
Интересно узнать альтернативные подходы, но чтобы удовлетворить это требование + чтобы было этими подходами удобно
+1
В чём преимущество перед сабмодулями?
0
Дело не в преимуществе, а в целесообразности. Главное отличие состоит в том, что при использовании submodules, пользователь снимает репозиторий-контейнер практически не настроенным и ему надо проделывать дополнительные мероприятия по согласованию ревизий подмодулей и репозитория-контейнера (так или иначе, это именно так, и автор проекта должен обеспечить пользователя соответствующими инструкциями, будь то простая инструкция по клонированию `git clone --recurse-submodules ...' или другое напоминание). Если же мы говорим о git-subrepo и git-subtree, то здесь, копируя репозиторий-контейнер, пользователь получает полностью настроенное дерево за одну операцию git-clone(1). Все для него уже сделано автором. А в остальном, все зависит от задач, которые решает автор и от его политики SCM (Source Configuration Management).
0
Т.е. правильно ли я понимаю, что раз тут все проделывается за одну команду git-clone, то интеграция с системами сборки получается прозрачная и автоматическая?
+1
Представим, например, следующую задачу. Ваш проект состоит из нескольких подпроектов/модулей и, допустим, один модуль представляет исходный код межмодульных интерфейсов. Набор интерфейсов, разрабатываемый отдельной командой, должен быть фиксирован для каждой ветки вашего проекта. Более того, никто из других команд разработчиков не должен иметь права изменять код интерфейсов, а наоборот, совершенствовать свой модуль в строгой согласованности с другими.
В этом случае CM инженер решит поставлять в каждую ветку проекта конкретные, фиксированыые ревизии интерфейсного модуля и постарается запретить любые комиты со стороны разработчиков. Только при переходе на новую версию интерфейсного модуля, все остальные команды создадут новые ветки собственных модулей, подключат к ним новую версию интерфейсного модуля и начнут работать над собственным кодом с целью приведения его в соответствие новой версии интерфейсов.
Согласитесь, что при данном подходе интерфейсный модуль лучше всего подключать не как submodule, обвязывая его хуками, а как subtree (а вот нужна ли при этом история интерфейсного модуля в общем индексе, это уже другой вопрос).
В этом случае CM инженер решит поставлять в каждую ветку проекта конкретные, фиксированыые ревизии интерфейсного модуля и постарается запретить любые комиты со стороны разработчиков. Только при переходе на новую версию интерфейсного модуля, все остальные команды создадут новые ветки собственных модулей, подключат к ним новую версию интерфейсного модуля и начнут работать над собственным кодом с целью приведения его в соответствие новой версии интерфейсов.
Согласитесь, что при данном подходе интерфейсный модуль лучше всего подключать не как submodule, обвязывая его хуками, а как subtree (а вот нужна ли при этом история интерфейсного модуля в общем индексе, это уже другой вопрос).
0
Ну фиг знает. Всё таки надёжнее каждый модуль проекта хранить в отдельной репе с полноценной историей. В основном проекте создаём папочку subreps, добавляем её в gitignore, в subreps клоним полноценные репы.
+1
Вот только что делать при таком подходе, если у вас несколько веток в проекте и к каждой отдельной ветке нужно подцеплять «свою» ветку из другого проекта. git subtree эту проблему решает на раз. Единственное неудобство — merge между своими ветками нужно делать осторожно, чтобы подпроекты не смержились.
0
А какая разница сколько веток и какой проект? Это ж полноценные репы, цепляйте что хотите.
+1
В проекте, над которым я работаю, мы используем submodule и каждая ветка основного проекта связана с конкретной веткой сабмодуля. Меняю ветку — сабмодуль тоже меняется, что я делаю не так?
0
Это если один проект. А если несколько проектов используют общий функционал? Если у каждого проекта своя репа и этот общий функционал нужно использовать в них. Сабмодули тут не подойдут.
0
Есть как минимум ещё один проект, где используется тот же самый сабмодуль.
0
А как вы разруливаете конфликты когда несколько разрабов работают над общей репой?
0
Как обычно, не вижу разницы, если честно. Фичи делаются в отдельных ветках, перед merge делаем rebase чтобы свести конфликты к минимуму, если какие-то ломающие изменения — то да, всем придётся править код, но только после принудительного обновления сабмодуля до мастера (т. е. ничего не ломается само по себе).
0
Насколько я знаю подмодули не работают без корневого репозитория, ветки наследуются от родителя и сабмодули не хранят историю изменений файлов, только хеш-сумму этих изменений. Из-за этого есть проблемы с мержем подмодулей в рамках проекта.
Возможно что-то изменилось с того момента, но насколько я вижу — нет.
Возможно что-то изменилось с того момента, но насколько я вижу — нет.
0
Ну как, у нас сабмодуль — это полноценный репозиторий. В том плане, что если изменения в проекте требуют изменений в сабмодуле — делается отдельная ветка и там и там, два пулл реквеста и т. д. За счёт линейной истории конфликты сведены к минимуму. Грубо говоря, для проекта сабмодуль — это внешний компонент, и конфликт сводится к тому, что есть хэш, в котором реализована фича А, и есть хэш, в котором она не реализована, ничего сложного.
Проблемы с мержем сабмодулей, про которые вы говорите, за полтора года работы над этим проектом встречались раза два.
Проблемы с мержем сабмодулей, про которые вы говорите, за полтора года работы над этим проектом встречались раза два.
0
git-subrepo и git-subtree не отменяет возможность ведения upstream-репозиториев как самостоятельных продуктов, а в основном дереве держать либо squashed-комиты, либо полноценные истории.
А на счет папочек в .gitignore все зависит от CM инженера. Либо он настраивает права пользователей и хуки, либо он отдает все на откуп инженерам команды разработчиков.
Товарищ Сухов сказал: «Лучше конечно помучиться.»
А на счет папочек в .gitignore все зависит от CM инженера. Либо он настраивает права пользователей и хуки, либо он отдает все на откуп инженерам команды разработчиков.
Товарищ Сухов сказал: «Лучше конечно помучиться.»
0
Sign up to leave a comment.
Git Subrepo