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

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

\main
    \ProductA
    \ProductB
    \Shared

затем

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

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

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

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

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

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

Ответы

Ответ 1

Руководство является простым в отношении Git пределов:

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

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

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

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

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

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

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

Я ответил:

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

Сказанное:

Ответ 2

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

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

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

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