Вам следует четко указать, о чем вы говорите, когда используете термин «поддерево» в контексте, git
поскольку на самом деле здесь есть две отдельные, но связанные темы:
Стратегия слияния git-subtree и git subtree .
TL; DR
Обе концепции, связанные с поддеревьями, позволяют эффективно управлять несколькими репозиториями в одном. В отличие от git-submodule, где в корневом репозитории хранятся только метаданные в форме .gitmodules , и вы должны управлять внешними репозиториями отдельно.
Подробнее
Стратегия слияния поддеревьев git - это, по сути, более ручной метод с использованием команд, на которые вы ссылались.
git-subtree - это сценарий оболочки-оболочки, обеспечивающий более естественный синтаксис. На самом деле это все еще часть contrib
и не полностью интегрировано в git с обычными страницами руководства. Документации вместо этого хранится вместе со стороны сценария.
Вот информация об использовании:
NAME
----
git-subtree - Merge subtrees together and split repository into subtrees
SYNOPSIS
--------
[verse]
'git subtree' add -P <prefix> <commit>
'git subtree' add -P <prefix> <repository> <ref>
'git subtree' pull -P <prefix> <repository> <ref>
'git subtree' push -P <prefix> <repository> <ref>
'git subtree' merge -P <prefix> <commit>
'git subtree' split -P <prefix> [OPTIONS] [<commit>]
Я наткнулся на довольно большое количество ресурсов по теме поддеревьев, так как планировал написать собственное сообщение в блоге. Я обновлю этот пост, если я это сделаю, но сейчас вот некоторая информация, имеющая отношение к рассматриваемому вопросу:
Многое из того, что вы ищете , можно найти на этом блоге Atlassian по Nicola Паолуччи соответствующий раздел ниже:
Зачем использовать поддерево вместо подмодуля?
Есть несколько причин, по которым вам может быть subtree
лучше использовать:
- Управлять простым рабочим процессом легко.
git
Поддерживаются более старые версии (даже более ранние v1.5.2
).
- Код подпроекта доступен сразу после
clone
завершения суперпроекта.
subtree
не требует от пользователей вашего репозитория изучать что-то новое, они могут игнорировать тот факт, что вы используете subtree
для управления зависимостями.
subtree
не добавляет новые файлы метаданных, как submodules
делает (т.е.
.gitmodule
).
- Содержимое модуля может быть изменено без наличия отдельной копии репозитория зависимости где-либо еще.
На мой взгляд, недостатки допустимы:
- Вы должны узнать о новой стратегии слияния (т.е.
subtree
).
- Вернуть код
upstream
для подпроектов немного сложнее.
- Ответственность за то, чтобы не смешивать код суперпроекта и подпроекта в коммитах, лежит на вас.
Я бы тоже согласился со многими из этого. Я бы порекомендовал ознакомиться со статьей, поскольку в ней рассказывается о некоторых типичных применениях.
Вы , возможно, заметили , что он также написал прослеживание здесь , где он упоминает важную деталь , что осталось от этого подхода ...
git-subtree
в настоящее время не удается включить пульт!
Эта близорукость, вероятно, связана с тем, что люди часто добавляют пульт вручную при работе с поддеревьями, но это также не сохраняется в git. Автор подробно описывает патч, который он написал, чтобы добавить эти метаданные в git-subtree
уже созданный коммит . Пока это не станет официальной основной веткой git, вы можете сделать что-то подобное, изменив сообщение фиксации или сохранив его в другом коммите.
Я также считаю этот пост в блоге очень информативным. Автор добавляет git-stree
к смеси третий метод поддерева, который он вызывает . Статью стоит прочитать, так как он довольно хорошо сравнивает три подхода. Он высказывает свое личное мнение о том, что ему нравится, а что нет, и объясняет, почему он создал третий подход.
Дополнительно
Заключительные мысли
В этом разделе показаны как мощь, так git
и сегментация, которая может произойти, когда функция просто не попадает в цель.
Лично у меня возникло отвращение, git-submodule
поскольку я нахожу это более запутанным для участников. Я также предпочитаю, чтобы ВСЕ мои зависимости управлялись в моих проектах, чтобы облегчить легко воспроизводимую среду, не пытаясь управлять несколькими репозиториями. git-submodule
однако, в настоящее время он гораздо более известен, поэтому, очевидно, хорошо знать об этом и зависит от вашей аудитории, которая может повлиять на ваше решение.