Макет сховища 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 коментарі :

Це звучить схоже на підтримку "зовнішніх", яку надає диверсія.
Ми спробували це і виявили надзвичайно громіздким постійно оновлювати посилання на версії в зовнішніх версіях, оскільки проекти розробляються одночасно із залежностями один від одного. Чи є інший варіант ??

@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"

Repo-per-project має переваги завдяки компонентності та спрощеній побудові за допомогою таких інструментів, як Maven. Repo-per-project додає захист, обмежуючи сферу того, що розробник змінює - з точки зору помилкових фіксів сміття.