Организация проекта с использованием Maven + Git

Question

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

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

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

• Большой проект - (здесь нет источника, только пом)
  • Бэкэнд-проект (источник + пом)
  • Клиенты (здесь нет источника, только пом)
    • Консоль (источник + пом)
    • Веб (источник + пом)

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

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

Answer 1

У меня есть проект maven, состоящий из более чем 60 модулей, и моя команда обсуждала один и тот же вопрос о том, где именно должны находиться корни репозитория git. До сих пор каждое обсуждение заканчивалось тем, что весь проект, вплоть до корневого модуля, оставлялся в одном и том же проекте. Решение в основном основано на удобстве разработчика - нам не нужно клонировать и открывать несколько разных репозиториев, чтобы работать в одном и том же проекте. Вопрос истории кажется мне фальшивым. Кого волнует, если история смешана? Вы всегда можете посмотреть историю / путь / файл конкретного файла в git, исключая любые другие.

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

Answer 2

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