Java 使用maven和多个git存储库—减少痛苦

我们最近从SVN迁移到git，大多数代码都在一个repo中，大多数项目都在自己的repo中（大约70个）。我们从这个java源代码构建了十几个不同的应用程序。这些应用程序都在*nix服务器上运行。我们使用maven和nexus来构建。当功能涉及多个回购协议时，我们中的许多人都在努力开发功能。以下是一些挑战：

• 开发人员必须分别对每个回购进行分支-我们对一个功能的所有分支使用相同的名称，以减少跟踪的难度

• 必须更新所有回购协议的POM，以指向每个回购协议工件的更新版本。如果有多个人在同一个分支上工作，可能会有很多其他人合并pom更改。当我提交对repo的更改时，工件被重命名为“-SNAPSHOT”，这意味着更多的pom更新

• 更改需要按正确的顺序推进，否则我们的自动构建将失败，例如：回购A取决于对回购B的更改；如果在构建和部署repo B之前推送repo A，则不会构建repo A

• 审查该功能的人员必须查看多个回购协议的变化

• 当该功能从其分支合并到（比如）主功能时，必须记住所有涉及的回购协议

看起来转向以单一回购为主的方式可能是最好的，但也有一些缺点：

• 用maven构建整个代码库需要很长时间。（为什么maven不能更像make，只构建已经改变或其依赖关系已经改变的东西？）

• 每次推送都会启动一大组构建和许多单元测试，而不仅仅是一个repo的工件构建和测试

• 通常在一个或两个回购协议中工作的开发人员更喜欢这种新的多重回购世界，并且会抵制这种改变

我已经研究了git子模块和子树，它们似乎并不能解决我们的许多问题（不确定GoogleRepo）。我们中的一些人使用诸如“mu”之类的工具来帮助他们。如果有一个工具包可以帮助开发人员在poms中维护版本，并跟踪整个REPO的变化，那将是一件好事

如果您有一套过程或工具用于简化这种环境中的开发，请告诉我

大多数项目都有自己的回购协议（约70个）`

对我来说，这就是问题的开始。我投票赞成大幅减少这一数字

如果你真的不想要一个单一的回购（1个回购得到我的选票），那么你可以将代码库分成n*change\u-frequency回购和1*change\u-frequency回购。保持n小是很重要的。这样可以避免重建很少更改的位

---

此外，即使使用单个repo，您也不需要按源引用所有内容，也不需要将二进制文件用于基本库。当基础库发生更改时，进行更改的人员还可以一次性更新所有引用，以便所有项目都是最新的。

我觉得您的问题太宽泛了。你可能想缩小范围以得到答案。