使用 Maven + Git 的项目组织答案

【问题标题】：Project Organization using Maven + Git使用 Maven + Git 的项目组织
【发布时间】：2011-10-28 09:59:55
【问题描述】：

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

目前，我们的项目通过 Maven 构建层次结构，但在文件层次结构/存储库方面是平坦的。我的目标是更紧密地匹配我们存储库中的 Maven 构建层次结构和文件结构层次结构，以使一切更容易理解。

我的问题是创建 Git 存储库以便维护文件层次结构/组织的适当级别是什么？示例：

大项目 - （这里没有来源，只是一个 pom）

后端项目（来源 + pom）

客户（这里没有来源，只是一个 pom）

控制台（来源 + pom）

网络（来源 + pom）

因此“仅 pom”项目将用于对实际源项目进行分组。但是 Git 存储库属于哪里？一些团队成员担心对 Web 项目的提交不属于 Console 项目的历史记录。但是如果 Git 存储库位于最低级别（树的叶节点），我们将失去文件结构组织（即使构建层次结构可以在 Maven 中维护）。

编辑：团队成员对提交历史的关注不如对标记的关注。鉴于 Git 存储库根位于 Big Project，并且我想标记 Web 项目（通过标记 Big Project），为什么该标记是否应该包含可能与 Web 标记无关的 Console 项目？

【问题讨论】：

你是如何在 SVN 中处理这个问题的？我假设你有一个像描述的结构。你简单地检查了大项目，其他所有东西都会放在硬盘上......那你为什么要改变这个？

标签： git maven structure tagging organization

【解决方案1】：

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

我们考虑过的一个选项是 git submodules，它允许您在 repos 中嵌入 repos。如果您决定分解层次结构，这可能是组织层次结构的一种选择。

【讨论】：

+1 表示单个项目。与 Subversion 和其他旧工具不同，这不是瓶颈。
您使用什么工具？我有一个类似的设置，在一个 git 存储库中有 20 个 maven 模块，包含 ±800000 行代码。由于不断的重新索引，我在使用 Egit 的 Eclipse 中遇到了严重的性能问题......
我们使用 IntelliJ，它处理得相当好，尤其是从版本 12 开始，但是在这个问题发生后的 1.5 年里，我们已经转向将模块分离为他们自己的项目住在他们自己的 repos 中，部分是为了避免 IDE 性能问题。这种方法会带来一系列问题，但也有其他好处。

【解决方案2】：

我建议让 Git 中的结构与 SVN 中的结构相同，这意味着一个包含整个项目的 Git 存储库。关键是您可以毫无问题地使用 Maven 发布插件进行此类多模块构建。

【讨论】：