Я бы предложил оставить структуру в Git такой же, как в SVN, что означает единое репозиторий Git с целым проектом. Дело в том, что вы можете без проблем использовать плагин Maven для таких сборок с несколькими модулями.

команда в настоящее время находится в процессе перехода от SVN к Git. В настоящее время мы используем Maven в качестве инструмента для сборки.

В настоящее время у наших проектов есть иерархия сборки через Maven, но они плоские на стороне файловой иерархии / хранилища. Моя цель - более точно сопоставить иерархию сборки Maven и иерархию файловой структуры в наших репозиториях, чтобы все было проще понять.

Мой вопрос: каков надлежащий уровень для создания репозиториев Git, чтобы поддерживать файловую иерархию / организацию? Пример:

Большой Проект - (здесь нет источника, только пом)Бэкэнд-проект (источник + пом)клиенты (здесь нет источника, только пом)Приставка (источник + пом)Web (источник + пом)

Таким образом, проект «pom only» будет использоваться для группировки реальных исходных проектов. Но где же находится репозиторий Git? Некоторые члены команды обеспокоены тем, что обязуетсяWeb Проект не принадлежит историиПриставка проект. Но если репозитории Git находятся на самых низких уровнях (конечные узлы дерева), мы теряем организацию файловой структуры (даже если иерархия сборки может поддерживаться в Maven).

Редактировать: Забота члена команды была не столько о истории коммитов, сколько о тегах. Учитывая, что корень репозитория Git находится наБольшой Проекти я хочу пометитьWeb проект (пометивБольшой Проект), почему этот тег должен включатьПриставка проект, который, возможно, не имеет отношения кWeb тег?

Ответы на вопрос(2)

Ваш ответ на вопрос