Когда разбить большой репозиторий Git на более мелкие?

Я работаю над переносом из SVN в Git. Я уже использовал git-svn, чтобы получить историю в один репозиторий git, и я уже знаю, как использовать git-subtree для разделения этого репозитория на более мелкие. Этот вопрос заключается не в том, как выполнить миграцию, а в том, когда нужно разделить и когда не разделить.

Я хочу разбить большой репозиторий, потому что некоторые из каталогов - это автономные библиотеки, которые также используются совместно с другими проектами. Раньше svn checkout выполнялось в библиотеке без необходимости проверки всего проекта. Во время всего этого я обнаружил, что, вероятно, есть десятки каталогов, которые имеют смысл находиться в собственном репозитории, потому что они 1) независимы и 2) разделены между проектами.

Как только вы выберете несколько репозиториев git, разумно использовать инструмент, облегчающий работу со многими репозиториями. Некоторые примеры: Google repo, git submodules, git subtree и создание пользовательского script (похоже, что хром делает это). Я изучил эти различные методы и понял, как их использовать.

Итак, вопрос о направлении перехода от подрывной деятельности.

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

Примечание. Источник необходимо проверить в Windows, MacOS и Linux.

ОТВЕТЫ

Ответ 1

Этот процесс может быть ориентирован на компонентный подход, где вы определили согласованный набор файлов (приложение, проект, библиотеку)

В терминах истории (в инструменте управления источником) когерентный набор означает, что он будет помечен, разветвлен или объединен как все, независимо от другого набора файлов.

Для распределенной системы управления версиями (например, git) каждый из этих наборов файлов является хорошим кандидатом для собственного репозитория git, и вы можете группировать те, которые вам нужны для конкретного проекта, в родительское репо с submodules.

Я описываю этот подход, например, в:

Противоположность (сохранение всего в одном репо) называется "системный подход", но может привести к огромному репо git, которое, как я упоминал в Производительность для Git" несовместимо с тем, как реализовано git.

OP onionjake запрашивает комментарии:

Не могли бы вы включить дополнительную информацию о тонкостях идентификации компонентов?

Этот процесс (идентификации "компонентов", который, в свою очередь, становится git repos), руководствуется архитектурой программного обеспечения вашей системы.
Любое подмножество, которое действует как независимый набор файлов, является хорошим кандидатом для собственного репо. Это может быть библиотека или dll, но также и часть приложения (GUI, клиент и сервер, диспетчер,...)

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

Ответ 2

Лично мне нравятся небольшие репозитории - они хорошо работают, когда у вас хорошая система управления зависимостями, например Composer for PHP.

Это устраняет проблему управления процессом проверки, а также отслеживает версии и т.д.

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

Ответ 3

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

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

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

Пример. Если вы вносите изменения в подмодуль, вы должны зафиксировать на субмодуле, push up, cd до супер-репо, добавить подмодуль в индекс/этап, зафиксировать его и снова нажать. его хлопот рабочего процесса. Не говоря уже о проблемах удаления, перемещения или переименования подмодуля.

Подделки

Git намного лучше. Истории переплетаются, но вы можете разделить каталог как поддерево при любой прихоти. Если вы решите, что вы больше не хотите, чтобы что-то было поддеревом... просто прекратите выполнение поддерева или нажмите.

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

Ответ 4

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

Критерии, которые я хотел бы использовать для создания репозитория субпроектов:

  • Используется ли он несколькими проектами?
  • Является ли он самодостаточным?
  • Часто ли это происходит?

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

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

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

Ответ 5

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

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

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

Я не буду беспокоиться о том, чтобы иметь десятки или потенциально сотни небольших репозиториев, если они каким-то образом независимы от основного репозитория. Наличие так много репозитория только увеличит время первой конфигурации вашего нового основного репозитория.

Вы должны одобрить решение большого репозитория, только если вам нужно перенести "немедленно" из подрывной деятельности. Или кто-то, у кого нет или мало знаний об альтернативах.

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