Когда разбить большой репозиторий Git на более мелкие?
Я работаю над миграцией из SVN в Git. Я уже использовал git-svn чтобы получить историю в одном репозитории git, и я уже знаю, как использовать git-subtree чтобы разделить этот репозиторий на более мелкие. Этот вопрос не о том, как сделать миграцию, а о том, когда разделить и когда не разделить.
Я хочу разделить большой репозиторий, потому что некоторые из каталогов являются автономными библиотеками, которые также совместно используются с другими проектами. Ранее svn checkout было сделано в библиотеке без необходимости проверки всего проекта. Во время всего этого я обнаружил, что, вероятно, есть десятки каталогов, которые имеют смысл быть в своем собственном репозитории, потому что они 1) независимы и 2) разделены между проектами.
как только вы получите выше нескольких репозиториев git, кажется разумным использовать инструмент, который упрощает работу со многими репозиториями. Некоторые примеры-Google repo, git submodules, git subtree, и создание пользовательского скрипт (похоже, что chromium делает это). Я изучил эти различные методы и понимаю, как их использовать.
таким образом, вопрос заключается в направлении перехода от subversion.
должен ли я пытаться придерживаться одного большого репозитория git, только разделяя его на меньшие части, когда это абсолютно необходимо, или я должен разделить его на десятки или потенциально сотни меньших репозиториев? С чем было бы проще работать? Есть еще решение, которое я пропустил? Если вы собираетесь со многими репозиториями, какой инструмент я должен использовать? Какие факторы заставят кого-то предпочесть один метод другому?
Примечание: источник должен быть проверен на Windows, MacOS и Linux.
5 ответов
этот процесс может управляться компонентный подход, где выявлен последовательный набор файлов (приложение, проект, Библиотека)
в терминах истории (в инструменте управления версиями), a последовательный set означает, что он будет помечен, разветвлен или объединен как все, независимо от другого набора файлов.
на распределенные система контроля версий (например, git), каждый из этих файлов является хорошим кандидат на собственное РЕПО git, и вы можете сгруппировать те, которые вам нужны для конкретного проекта в Родительском РЕПО с подмодулей.
я описываю этот подход, например в;
- "настройка репозитория Git для проекта с сервером и клиентом "(сервер и клиент-два очевидных когерентных отдельных набора, которые выигрывают от наличия собственного РЕПО)
- "что компонент-управляется Развитие?"
противоположное (сохранение всего в одном РЕПО) называется "
лично мне нравятся небольшие РЕПО - они хорошо работают, когда у вас есть хорошая система управления зависимостью, такая как Composer для PHP.
Он забирает боль от управления процессом проверки, а также отслеживает версии и т. д.
Он также позволяет РЕПО размещаться различными поставщиками. Мы используем комбинацию кода на заказ и РЕПО с открытым исходным кодом.
Я бы сказал, Идите с поддеревьями большую часть времени, если не все время - и не стесняйтесь делать поддеревья свободно, как вы считаете необходимым.
С большим количеством зависимостей, submodules начинают становиться болезненными. Если вы оказываете какое-либо влияние на развитие этих зависимостей, то это происходит вдвойне. Подмодуль может быть в порядке, если у вас есть полностью сторонняя библиотека, которая не меняет версии очень часто, и вы никогда не будете активно развиваться как часть вашего большого проекта.
подмодули слишком отделены от супер-РЕПО для зависимостей, над которыми вы действительно работаете.
пример: Если вы вносите изменения в подмодуль, вам нужно зафиксировать подмодуль, нажать вверх, cd до супер РЕПО, добавить подмодуль в индекс/этап, зафиксировать его и снова нажать вверх. его от рабочего процесса. Не говоря уже о хлопотах по удалению, перемещению или переименованию подмодуля.
поддеревья Git намного лучше. Истории переплетены, но вы можете разделите каталог как поддерево по любой прихоти. Если вы решите, что больше не хотите, чтобы что-то было поддеревом... просто прекратите выполнять разделение поддерева или толчки.
недостатком поддеревьев является то, что они вообще не отслеживаются. Таким образом, вы должны помнить все пути и их отношение к своим репозиториям - и любой, кто работает над проектом, также должен знать, что если они хотят выполнять операции поддерева. Хорошая новость в том, что большинство разработчиков могут просто работать над любым кодом на любой из зависимостей, не беспокоясь о том, как он будет вытеснен в эти репозитории. Кроме того, как вы сказали, некоторые сценарии bash могут автоматизировать ручной материал.
когда у вас есть хороший вариант повторного использования для нескольких проектов, рассмотрите возможность его разделения на подпроект. Я бы избегал создания общего проекта, прежде чем у вас будет два проекта, которые его используют.
критерии, которые я бы использовал для рассмотрения возможности создания РЕПО подпроекта:
- используется ли он несколькими проектами?
- это самодостаточное?
- он часто меняется?
Я нахожу поддеревья проще всего управлять в том, что я могу развивать библиотека как часть проекта, а затем разделить его, когда возникает необходимость.
Я также хотел бы отметить, что для 2 проектов вполне нормально расходиться по общим библиотекам и часто предпочтительнее, чтобы держать их в стабильном состоянии. Пока легко сходится общий код, я не вижу вреда в ленивом подходе к совместному использованию библиотек.
в любом случае, это хороший знак, чтобы иметь эту проблему; это означает, что вы проделали хорошую работу по созданию повторно используемого кода. :)
когда вы работаете в распределенной среде, предоставляя функции git, вы должны избегать прямого группирования различных компонентов в один репозиторий, если эти компоненты используются другими проектами или если вы планируете это сделать. Или, если это возможно или желательно, это произойдет в будущем.
Это потому, что разработчики/авторы смогут сосредоточиться на своей части без необходимости скачать полную историю всех других компонентов, они не собираются использовать/изменить. Думаю, что это также важно, если вы работаете с поставщиками из стран/регионов, где скорость интернета медленнее, чем мы привыкли по.
Как вы пытались понять различные методы, вы не застряли с низким уровнем знаний, и это не должно быть трудно трудной задачей. Насколько я знаю, у вас есть все возможные варианты.
Я не буду беспокоиться о наличии десятков или потенциально сотен меньших репозиториев, если они каким-то образом независимы от основного хранилище. Наличие такого количества репозиториев только увеличит время первой настройки вашего нового основного репозитория.
вы должны отдать предпочтение решению большого репозитория, только если вам нужно мигрировать "немедленно" из subversion. Или кто-то, у кого нет или мало знаний об альтернативах.
Я хотел бы использовать git subtree потому что он доступен с Git в качестве стандартных функций: пользователи не будут обязаны устанавливать что-либо дополнительное, чем git, и он будет продолжать оставаться вокруг, пока git будет.