Когда использовать поддерево git?

какую проблему git subtree решить? Когда и почему я должен использовать эту функцию?

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

этот учебник GitHub объясняет как выполнить слияния поддерева Git.

Я знаю как использовать его, но не , когда (вариантами использования) и почему и как это относится к git submodule. Я бы использовал подмодули, когда у меня есть зависимость от другого проекта или библиотеки.

37
git git-subtree

5 ответов

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

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

TL; DR

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

Более Подробная Информация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Закрытие Мысли

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

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

20

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

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

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

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

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

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

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

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

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

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

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

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

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

8

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

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

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

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

как этого избежать управление РЕПО многих и многих отраслей. git-subtree увеличил нашу производительность в несколько раз!

1

в основном git-поддерево являются альтернативами подхода Git-подмодуля: Есть много недостатков или, скорее, я бы сказал, вам нужно быть очень осторожным при использовании git-подмодулей. e.g Когда у вас есть" одно "РЕПО и внутри "одного", вы добавили другое РЕПО, называемое" два", используя подмодули. Вещи, которые вы должны заботиться:

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

  • когда неизвестный пользователь пытается клонировать ваше" одно "РЕПО, после клонирования" одного "этот пользователь должен обновить подмодули, чтобы получить" два " РЕПО

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

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

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

Ура!

0

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

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

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

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

0