Comments 6
Спасибо за исчерпывающее руководство по инструменту.
Почитать и поэкспериментирвать было очень интересно, но в рабочих проектах постараюсь не использовать. Слишком много требуется ручной работы с гитом, GUI (напримет, плагин от JetBrains) эти функции скорее всего не поддерживает, а поломать что-то неосторожным движением кажется весьма вероятным.
На моей версии git 2.25.1 из стандартной поставки ubuntu 20.04 ppa комманда git-subtree исключена из автодополнения, что привносит свои неудобства; к тому же у меня нет опции --list
$ git version
git version 2.25.1
$ git subtree --help
usage: git subtree add --prefix=<prefix> <commit>
or: git subtree add --prefix=<prefix> <repository> <ref>
or: git subtree merge --prefix=<prefix> <commit>
or: git subtree pull --prefix=<prefix> <repository> <ref>
or: git subtree push --prefix=<prefix> <repository> <ref>
or: git subtree split --prefix=<prefix> <commit>
-h, --help show the help
-q quiet
-d show debug messages
-P, --prefix ... the name of the subdir to split out
-m, --message ... use the given message as the commit message for the merge commit
options for 'split'
--annotate ... add a prefix to commit message of new commits
-b, --branch ... create a new branch from the split subtree
--ignore-joins ignore prior --rejoin commits
--onto ... try connecting new tree to an existing one
--rejoin merge the new branch back into HEAD
options for 'add', 'merge', and 'pull'
--squash merge subtree changes as a single commit
В отличие от Git, Subversion предоставляет такие возможности весьма просто и понятно, однако давно уже не в моде.
Поигрался тут на досуге. Если честно, то не понял. Ну вообще никак. Точнее как средство отделить часть репозиториря в отдельный проект - нормально. Но вот стоит задача: есть 5 проектов, и хочется общую часть поместить в один общий. Причём хочется, что бы ссылаться можно было как на конкретный коммит, так и на бранч и что бы при заборе любого из 5 проектов всегда забирался самый последний коммит с общего.
Ни сабмодули, но subtree этого не помогают сделать:
При использовании сабмодулей, ревизия хранится в в мастер-репозитории. И сделав банальный
git clone --recurisve REPO, вы не получите последний коммит из сабмодуля, даже если укажите банч для трекинга. Итого, потом нужно будет сделатьgit submodule update --remote, после чего мастер-репозиторием это воспринимается как модификация и нужноgit commit/git pushсделать. Как поведение по-умолчанию, это норм - ты закрепляешь ревизию, и случайно не поломаешь сборку. Но если сабмодуль ваш на пачку сервисов, то удобнее трекать именно бранч, а если сборка сломается, то чинить мастер-репозиторий, обычно это свидетельствует об его неконсистентности.На сабмодулях тоже самое. Обычный
git pullне заберёт последние данные из upstream, более того, что бы забрать нужно ещё и указать полный путь каждый раз до апстрима.
Сейчас выходит, что флоу более-менее релевантен для сабмодулей (с настроенным git submodule set-branch ...):
git pull
git submodule --remote
# если видишь изменеия в сабмодулях
git add submodule_dir
git commit
Что тут сказать? Я исследовал возможности Git. Эти исследования показали, что Git требует от пользователя слишком много телодвижений, а subtree вообще скоро канет в лету.
Между тем, ваша задача элементарна для Subversion. Механизм svn externals решает ее запросто и безо всяких проблем.
Это я знаю, как и возможность "частичных" мёржей. Но в SVN, мне очень мешает централизация, отсутствие возможности быстрого бранчевания, всякие blame (svn ann) отрабатывают реактивно, а, при наличии тестов, делать бинарный поиск сломавшего коммита вообще прелесть. SVN тут почти на каждый чих лезет на сервер. Делать локально коммиты на каждый чих или мелкое изменение, без боязни пропустить или сломать что-то, особенно когда активно что-то исследуешь/пробуешь, а потом сделать rebase -i и причесать код - по мне прям вот золото, хотя есть и те, кто против этого, против редактирования истории.
Но это уже вопросы религии) В целом, Git мне больше по душе.
Git subtree в деталях