使用 Maven 组织项目git
我们的团队目前正在从 SVN 迁移到 Git。我们目前使用 Maven 作为我们的构建工具。
目前，我们的项目通过 Maven 有一个构建层次结构，但在文件层次结构/存储库方面是平坦的。我的目标是更紧密地匹配我们存储库中的 Maven 构建层次结构和文件结构层次结构，以使一切更容易理解。
我的问题是创建 Git 存储库的正确级别是什么，以便维护文件层次结构/组织？例子：
- 大项目 - （这里没有来源，只是一个 pom）
- 后端项目（源代码 + pom）
- 客户端（这里没有来源，只是一个 pom）
- 控制台（源代码 + pom）
- 网页（源代码 + pom）
因此，“仅 pom”项目将用于对实际源项目进行分组。但是 Git 存储库属于哪里？一些团队成员担心对 Web 项目的提交不属于 Console 项目的历史记录。但是，如果 Git 存储库位于最低级别（树的叶节点），我们就会丢失文件结构组织（即使可以在 Maven 中维护构建层次结构）。
编辑：团队成员关心的不是提交历史记录，而是标记。鉴于 Git 存储库根位于 Big Project，并且我想标记 Web 项目（通过标记 Big Project），为什么该标签是否应该包含 Console 项目，该项目可能与 Web 标签无关？
Our team is currently in the process of moving from SVN to Git. We currently use Maven as our build tool.
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.
My question is what is the proper level to create Git repos so that the file hierarchy/organization is maintained? Example:
- 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)
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).
Edit: 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我有一个由 60 多个模块组成的 Maven 项目，我的团队讨论了同样的问题，即 git 存储库根到底应该在哪里。到目前为止，每次讨论都以将整个项目（一直到根 pom）留在同一个项目中结束。该决定主要基于开发人员的便利性——我们不必克隆和打开多个不同的存储库来在本质上相同的项目中工作。历史问题对我来说似乎是虚假的。谁在乎历史是否混合？您始终可以在 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.
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.
我建议保留 Git 中的结构与 SVN 中的结构相同，这意味着单个 Git 存储库中包含整个项目。重点是，对于此类多模块构建，您可以毫无问题地使用 Maven 发布插件。
I would suggest to leave the structure in Git the same as in SVN which means a single Git repos with the whole project in it. The point is you can use the Maven release plugin without any problems for such kind of multi-modules builds.