Ответ 1

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

стратегия слияния git-subtree и git subtree.

TL; DR

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

Подробнее

Стратегия слияния git поддеревья - это в основном более ручной метод с использованием команд, на которые вы ссылаетесь

git-subtree - это сценарий оболочки-обертки для упрощения синтаксиса. На самом деле это все еще часть contrib и не полностью интегрированная в git с обычными man-страницами. Документация хранится вместе со сценарием.

Вот информация об использовании:

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

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

Существует несколько причин, по которым вам может пригодиться subtree:

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

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

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

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

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

git-subtree настоящее время не включает удаленный!

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

Здесь моя точка зрения, основанная на вышесказанном:

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

ОБНОВИТЬ

Подробнее о решении, которое было размещено в комментариях:

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

Наше клиентское репо также имело сценарии, которые мы также адаптировали для этого конкретного клиента.

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

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

Ответ 4

В принципе Git -subtree являются альтернативами подхода Git -submodule: Есть много недостатков или, скорее, я бы сказал, вам нужно быть очень осторожными при использовании Git -подмодулей. например, когда у вас есть "одно" репо, а внутри "одного" вы добавили другое репо под названием "два" с использованием подмодулей. Вещи, которые вам нужно позаботиться:

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

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

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

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

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

Ура!

Ответ 5

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

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

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

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