Вам следует четко отметить, о чем вы говорите, когда используете термин 'поддерево' в контексте git, поскольку на самом деле здесь есть две отдельные, но связанные темы:

git-subtree и стратегия слияния поддеревьев git.

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 blog Никола Паолуччи в соответствующем разделе ниже:

Зачем использовать поддерево вместо подмодуля?

Есть несколько причин, по которым вам может показаться, что subtree лучше использовать:

• Управлять простым рабочим процессом легко.
• Поддерживаются более старые версии git (даже до v1.5.2).
• Код подпроекта доступен сразу после завершения clone суперпроекта.
• subtree не требует от пользователей вашего репозитория изучения чего-либо нового, они могут игнорировать тот факт, что вы используете subtree для управления зависимостями.
• subtree не добавляет новые файлы метаданных, как submodules (т. Е. .gitmodule).
• Содержимое модуля может быть изменено без наличия отдельной копии репозитория зависимости где-либо еще.

На мой взгляд, недостатки допустимы:

• Вы должны узнать о новой стратегии слияния (например, subtree).
• Вернуть код upstream для подпроектов немного сложнее.
• Ответственность за то, чтобы не смешивать код суперпроекта и подпроекта в коммитах, лежит на вас.

Я бы тоже согласился со многими из этого. Я бы порекомендовал ознакомиться со статьей, поскольку в ней рассказывается о некоторых типичных применениях.

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

git-subtree в настоящее время не может включить пульт!

Эта близорукость, вероятно, связана с тем, что люди часто добавляют пульт вручную при работе с поддеревьями, но это также не сохраняется в git. Автор подробно описывает патч, который он написал, чтобы добавить эти метаданные в коммит, который git-subtree уже генерирует. Пока это не станет официальной основной веткой git, вы можете сделать что-то подобное, изменив сообщение коммита или сохранив его в другом коммите.

Я также считаю очень информативным этот пост в блоге. Автор добавляет в смесь третий метод поддерева, который он называет git-stree. Статью стоит прочитать, так как он неплохо сравнивает три подхода. Он высказывает свое личное мнение о том, что ему нравится, а что нет, и объясняет, почему он создал третий подход.

Дополнительно

• список git-поддеревьев
• Отсоединить подкаталог

Заключительные мысли

В этом разделе показаны как мощь git, так и сегментация, которая может произойти, когда функция просто не попадает в цель.

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

Во-первых: я считаю, что на ваш вопрос обычно приходят категоричные ответы, и здесь его можно считать не по теме. Однако мне не нравится такая политика SO, и я бы немного раздвинул границу темы, поэтому я предпочитаю отвечать и надеюсь, что другие тоже.

В руководстве GitHub, на которое вы указали, есть ссылка на Как используйте стратегию слияния поддеревьев, которая дает представление о преимуществах / недостатках:

Сравнение слияния поддеревьев с подмодулями

Преимущество использования слияния поддеревов заключается в том, что оно требует меньше административной нагрузки со стороны пользователей вашего репозитория. Он работает со старыми (до Git v1.5.2) клиентами, и у вас есть код сразу после клонирования.

Однако, если вы используете подмодули, вы можете не переносить объекты подмодуля. Это может быть проблема слияния поддерева.

Кроме того, если вы вносите изменения в другой проект, проще отправить изменения, если вы просто используете подмодули.

Вот моя точка зрения, основанная на вышеизложенном:

Я часто работаю с людьми (= коммиттерами), которые не являются постоянными пользователями git, некоторые все еще (и всегда будут) бороться с контролем версий. Обучить их тому, как использовать стратегию слияния подмодулей, в принципе невозможно. Он включает в себя концепции дополнительных пультов дистанционного управления, слияния, разветвлений и последующего объединения всего этого в один рабочий процесс. Извлечение из восходящего потока и продвижение вверх по течению - двухэтапный процесс. Поскольку ветки им сложно понять, это все безнадежно.

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

Имхо проще предоставить простые сценарии оболочки для рабочего процесса подмодуля.

Для больших супер-репозиториев с множеством вспомогательных репозиториев важным преимуществом подмодулей является отказ от клонирования данных некоторых вспомогательных репозиториев. Мы можем ограничить это в зависимости от требований к работе и использования дискового пространства.

Контроль доступа может быть другим. У меня еще не было этой проблемы, но если для разных репозиториев требуются разные элементы управления доступом, эффективно запрещая некоторым пользователям доступ к некоторым вспомогательным репозиториям, мне интересно, проще ли это сделать с помощью подхода подмодулей.

Лично я сам не решил, что использовать. Разделяю ваше недоумение: o]

По сути, Git-subtree - это альтернатива подходу Git-submodule: есть много недостатков или, скорее, я бы сказал, вам нужно быть очень осторожным при использовании git-submodules. например, когда у вас есть «одно» репо, а внутри «одного» вы добавили другое репо с именем «два», используя подмодули. О чем нужно позаботиться:

• Когда вы меняете что-то в «два», вам нужно зафиксировать и нажать внутрь «два», если вы находитесь в каталоге верхнего уровня (то есть в «один»), ваши изменения не будут выделены.

• Когда неизвестный пользователь пытается клонировать ваше «одно» репо, после клонирования «одного» этому пользователю необходимо обновить подмодули, чтобы получить репо «два».

Вот некоторые моменты, и для лучшего понимания я бы порекомендовал вам посмотреть это видео: https://www.youtube.com/watch?v=UQvXst5I41I

• Для решения таких проблем изобретен подход поддерева. Чтобы получить основы работы с git-subtree, просмотрите следующее: https://www.youtube.com/watch?v=t3Qhon7burE

• Я считаю, что подход поддерева более надежен и практичен по сравнению с подмодулями :) (я очень новичок, чтобы говорить эти вещи)

Ваше здоровье!

Реальный вариант использования, который у нас есть, когда git subtree было спасением:

Основной продукт нашей компании является высокомодульным и разработан в нескольких проектах в отдельных репозиториях. У всех модулей есть отдельная дорожная карта. Весь продукт состоит из всех модулей конкретных версий.

Параллельно настраивается конкретная версия всего продукта для каждого из наших клиентов - отдельные филиалы для каждого модуля. Иногда настройку приходится производить сразу в нескольких проектах (cross-module customization).

Чтобы иметь отдельный жизненный цикл продукта (обслуживание, функциональные ветки) для индивидуализированного продукта, мы ввели git subtree. У нас есть один репозиторий git-subtree для всех настраиваемых модулей. Наша настройка - это ежедневный возврат к исходным репозиториям и ветвям настройки при помощи git subtree push.

Таким образом мы избегаем управления множеством репо и множеством филиалов. git-subtree увеличил нашу продуктивность в несколько раз!

ОБНОВЛЕНИЕ

Подробнее о решении, опубликованном в комментариях:

Мы создали совершенно новый репозиторий. Затем мы добавили каждый проект, у которого была клиентская ветвь, в это новое репо как поддерево. У нас была работа Дженкинса, которая регулярно отправляла основные изменения в исходные репозитории в клиентскую ветку. Мы работали только с «клиентским репо», используя типичный поток git с ветвями функций и обслуживания.

В нашем «клиентском» репозитории также были скрипты для сборки, которые мы также адаптировали для этого конкретного клиента.

Однако есть подводный камень представленного решения.

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

Чтобы добавить к приведенным выше ответам, дополнительным недостатком использования поддерева является размер репо по сравнению с подмодулями.

У меня нет никаких реальных показателей, но с учетом того, что каждый раз, когда выполняется push в модуле, везде, где этот модуль используется, получает копию того же изменения в родительском модуле (когда впоследствии обновляется в этих репозиториях).

Так что, если кодовая база сильно модульна, она довольно быстро накапливается.

Однако, учитывая, что цены на хранение всегда снижаются, это не может быть существенным фактором.