Макет репозитория GIT для сервера с несколькими проектами

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

\main
    \ProductA
    \ProductB
    \Shared

затем

svn checkout http://.../main/ProductA

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

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

Между продуктами существуют зависимости, поэтому единый масштабный проект кажется подходящим. Мы будем использовать сервер, на котором все разработчики смогут делиться своим кодом. У меня уже есть эта работа над SSH и HTTP, и эта часть мне нравится. Однако размер репозиториев в SVN уже составляет много ГБ, поэтому перетаскивание всего репозитория на каждой машине кажется плохой идеей - тем более, что нам выставлен счет за чрезмерную пропускную способность сети.

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

Есть ли какие-либо рекомендации или лучшие практики для работы с очень большими многопроектными репозиториями?

Рекомендации относительно ограничений Git просты :

• одно репо на проект
• основной проект с подмодулями .

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

В OP Paul Alexander комментарии :

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

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

• разрабатывайте свои подпроекты непосредственно из основного проекта (как описано в разделе « Истинная природа подмодулей »),
• или вы ссылаетесь в суб-репо на originто же суб-репо, которое разрабатывается в другом месте: оттуда вам просто нужно извлечь из этого суб-репо изменения, внесенные в другом месте.

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

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

Я ответил:

Честно говоря, возможно, вы были правы ... это было до последней версии Git 1.7.1 .
git diffи git statusоба научились учитывать состояния подмодулей, даже если они выполняются из основного проекта.
Вы просто не можете пропустить модификацию подмодуля.

Что, как говорится:

• подмодули отличаются от внешних SVN: см. « Почему подмодули git несовместимы с внешними svn? »
• управление подмодулями может быть непростым: см. « Как именно работает подмодуль git? ».

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

super-repo
+- module-a-repo
+- module-b-repo

gits clone url-super-repo
gits commit -a -m "msg"

Репо-на-проект имеет преимущества с разбивкой на компоненты и упрощенной сборкой с такими инструментами, как Maven. Репо-на-проект добавляет защиту, ограничивая объем того, что изменяет разработчик - с точки зрения ошибочных коммитов мусора.