Разделение проекта на несколько репозиториев git

Question

Я новичок в git, и мне было поручено переместить существующий проект в git. Проблема у меня в том, что это действительно 2 проекта. Назовем проект «Один». Один из них на самом деле является как сайтом отчетности, так и группой шаблонов кода, которые используются отдельными проектами (что позволяет сайту отчетов запускать стандартные отчеты по проектам). Мы хотим запустить сайт отчетности на наших dev & серверах отчетов и иметь шаблоны кода на наших dev и производственных серверах. Так, иногда оба хранилища будут необходимы, и только 1. А иногда даже один был написан со структурой кода, как это:

/one (generic main dir, no files, only sub-dirs) 
    /onesource (PHP source code for the reporting site) 
    /onerept (reports run by the reporting site) 
    /onelib  (templates) 
    /oneinc  (include files used by templates) 
    /oneadmn (files used by both) 

Таким образом, хранилище сайта отчетности нужно будет содержать OneSource и onerept суб-каталоги, в то время как репозиторий шаблонов захочет содержать каталоги onelib и oneinc. Я могу сделать oneadmn dir в совместное монтирование между серверами, если это необходимо. В настоящее время все настроено как совместное монтирование, но это плохо по нескольким причинам.

Как установить это в git?

Answer 1

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

Другие варианты:

1) Создайте отдельную ветку для каждой среды. Используйте один и тот же репозиторий git, но разные ветви для каждой среды.

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

Это одна вещь, с которой git не справляется очень хорошо - наличие иерархии отдельных хранилищ, склеенных вместе. Я использовал второй подход в одном из моих проектов, который состоит из нескольких исходных репозиториев верхнего уровня и некоторых разделяемых модулей. Каждый проект верхнего уровня представляет собой отдельный филиал в исходном проекте. Чтобы работать над проектом верхнего уровня, я клонирую основной репозиторий в новый рабочий каталог, а затем клонирую репозиторий совместно используемого модуля в подкаталоге «libs» в рабочем каталоге.

Это не идеальный сценарий, но он обычно работает. Просто нужно быть немного организованным и иметь в виду, что подкаталог «libs» представляет собой отдельный репозиторий git.

В вашем случае вы перемещаете «onelib» и «oneinc» во второй репозиторий git и клонируете его в отдельный подкаталог, называемый «shared», я полагаю. Затем вам нужно будет изменить остальную часть кода на ссылку «shared/onelib» и «shared/oneinc», в этом случае.

Answer 2

Стандартное правило: все, что разработано, версировано и выпущено вместе, входит в один репозиторий. Следовательно, части проекта с независимыми номерами версий переходят в собственное репо.

Причина в том, что ветви и теги в git всегда доступны в репозитории (в отличие от Subversion).

По этому правилу я бы сказал, что все должно идти в одно большое репо.

---

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

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