Один проект Java с несколькими репозиториями Git

Question

У нас есть один большой веб-проект java, и мы используем Git локально, и у нас есть Stash в качестве внутреннего Git-сервера для фиксации/продвижения нашего кода.

Ниже перечислены все отдельные Репо в нашем мерзавца:

repo - java/spring/maven/hibernate entity and dao's jar 
repo - java/spring/maven - business services 1 which makes use of the previous jar 
repo - java/spring/maven - business services 2 which makes use of the previous jar 
repo - java/spring/maven - business services 3 which makes use of the previous jar 
repo - java/spring/maven/smartgwt - business services 2 which makes use of the previous 3 business service jars. 

Все они строят отдельно их собственный файл Maven pom.xml. В этой архитектуре, когда мы добавляем новый метод DAO, мы помещаем аналогичный вызов Business Service в , а затем добавляем веб-службу GET для обработки вызова этой новой бизнес-службы.

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

бы лучшим решением, чтобы:

repo - Project_BackEnd, which contains 3 or more sub-modules 
submodule- java/spring/maven - business services 1 which makes use of the previous jar 
submodule- java/spring/maven - business services 2 which makes use of the previous jar 
submodule- java/spring/maven - business services 3 which makes use of the previous jar 

repo - Project_FrontEnd 
submodule - java/spring/maven/smartgwt - business services 2 which makes use of the previous 3 business service jars. 

я взглянуть на конкретном примере Git с несколькими ява Spring проектов, но ничего не нашли. Прошу прощения, если это дубликат других вопросов.

ОБНОВЛЕНИЕ: Несмотря на то, что я не против отдельных git-репозиций для разных аспектов одного общего проекта, мои коллеги, которые больше не являются git-экспертами, чем я, считают это громоздким и не видят общих будущих преимуществ git и я не хочу, чтобы мы возвращались в SVN.

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

Возможно, было бы проще создать git-repo для бэкэнд. Поскольку мы используем maven, у нас может быть родительский проект maven, а затем создавать модули maven. Таким образом, у различных фоновых библиотек будут свои собственные файлы pom.xml и по-прежнему будут создавать разные банки.

Любое изменение в любом из этих подмодулей затем инициирует изменение, а CI может выполнить сборку этого проекта.

Мысли?

Answer 1

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

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

Так как:

• использовать IDE, который может тянуть/толкать несколько сделок РЕПО сразу, как IntelliJ.
• Объединение нескольких репозиториев в одном Git-репо с родительским POM-сервером Maven и несколькими модулями. Основным недостатком этого является то, что ваша система CI не будет знать, какой конкретный модуль был обновлен и, возможно, потребуется построить полное репо, когда вам нужно будет только перестроить один модуль.