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

Question

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

\main
    \ProductA
    \ProductB
    \Shared

тогда

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

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

1. Настройка отдельного проекта для каждого продукта.
2. Настройка одного крупного проекта и хранение продуктов в подпапках.

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

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

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

Answer 1

Руководство простое в отношении Ограничения Git :

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

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

---

ОП Пол Александр комментарии :

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

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

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

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

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

Я ответил:

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

Как говорится:

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

Answer 2

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

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

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

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