使用Maven + Git的项目组织 [英] Project Organization using Maven + Git

查看:189
本文介绍了使用Maven + Git的项目组织的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们的团队目前正在从SVN转移到Git。我们目前使用Maven作为我们的构建工具。

Our team is currently in the process of moving from SVN to Git. We currently use Maven as our build tool.

目前我们的项目通过Maven具有构建层次结构,但在文件层次结构/存储库一侧是平坦的。我的目标是更紧密地匹配Maven构建层次结构和我们仓库中的文件结构层次结构,以便更容易理解。

Currently our projects have a build hierarchy through Maven, but are flat on the file hierarchy/repository side. My goal is to more closely match the Maven build hierarchy and the file structure hierarchy in our repositories in order to make everything easier to understand.

我的问题是什么创建Git仓库以便维护文件层次/组织?例如:

My question is what is the proper level to create Git repos so that the file hierarchy/organization is maintained? Example:



  • 大项目 - (这里没有源代码,只是一个pom)

    • 后端项目(源+ pom) 在这里,只是一个POM)

      • 控制台(源+ pom) strong>(source + pom)

  • Big Project - (no source here, just a pom)
    • Backend Project (source + pom)
    • Clients (no source here, just a pom)
      • Console (source + pom)
      • Web (source + pom)

因此,pom only项目将用于对实际的源项目进行分组。但是,Git仓库属于哪里?一些团队成员担心,对 Web 项目的提交不属于控制台项目的历史记录。但是,如果Git回收站处于最低级别(树的叶节点),我们将丢失文件结构组织(即使构建层次结构可以在Maven中维护)。

So the "pom only" project would be used to group actual source projects. But where does the Git repo belong? Some team members are concerned that commits to the Web project don't belong in the history for the Console project. But if the Git repos are at the lowest levels (the leaf nodes of the tree), we lose the file structure organization (even though the build hierarchy can be maintained in Maven).

编辑:团队成员对提交历史记录的担忧不像使用标记一样。鉴于Git repo root位于 Big Project ,我想标记 Web 项目(通过标记 Big Project ),为何该标签是否包含控制台项目,这可能与网页标记不相关?

The team member's concern wasn't as much with commit history as it was with Tagging. Given that the Git repo root is at the Big Project, and I want to tag the Web project (by tagging the Big Project), why should that tag include the Console project, which maybe not in relevant to the Web tag?

推荐答案

我有一个由60多个模块组成的maven项目,我的团队已经讨论了git存储库根目录应该在哪里的相同问题。到目前为止,每一次讨论都以同一个项目中的整个项目结束,直到根源。这个决定主要基于开发人员的便利 - 我们不需要克隆和打开多个不同的存储库,以在本质上相同的项目中工作。历史问题对我来说似乎是虚假的。谁在乎历史是否融合?你可以在git中看到特定文件/模块/路径的历史记录,不包括任何其他文件。

I have a maven project consisting of over 60 modules, and my team has discussed the same question of exactly where the git repository roots should be. So far, every discussion has ended with leaving the entire project, all the way up to the root pom, in the same project. The decision is mainly based around developer convenience--we don't have to clone and open multiple different repositories to work in what's essentially the same project. The question of history seems bogus to me. Who cares if the history is blended? You can always see a particular file's/module's/path's history in git, exclusive of any others.

我们考虑的一个选项是 git submodules ,它可以让你在repos中嵌入repos。如果您决定拆分它,这可能是组织您的层次结构的一种选择。

An option we've considered is something called git submodules, which let you embed repos within repos. This could be an option for organizing your hierarchy if you decide to break it up.

这篇关于使用Maven + Git的项目组织的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆