我们最近从SVN迁移到git，大多数项目都在自己的存储库中(大约70个(。我们从这个 java 源代码构建了大约十几个不同的应用程序。这些应用程序都在 *nix 服务器上运行。我们使用maven和nexus来构建。当该功能涉及多个存储库时，我们中的许多人都在努力开发该功能。以下是一些挑战：
-
开发人员必须单独分支每个存储库 - 我们对一个功能的所有分支使用相同的名称，以降低跟踪的难度。
必须更新所有存储库的 poms，以指向每个存储库工件的更新版本。如果多个人在同一个分支上工作，则可能会有很多合并其他pom更改。当我提交对存储库的更改时，工件将重命名为"-SNAPSHOT"，这意味着更多的pom更新。
更改需要以正确的顺序推送，否则我们的自动生成将失败，例如：存储库 A 依赖于对存储库 B 的更改;如果在存储库 B 构建和部署之前推送存储库 A，则存储库 A 不会生成。
查看该功能的人员必须查看多个存储库中的更改。
当功能从其分支合并到(例如(主节点时，必须记住所有被触及的存储库。
看起来切换到主要是单存储库的方法可能是最好的，但那里有一些缺点：
-
使用 maven 构建整个代码库需要很长时间。(为什么 maven 不能更像 make，只构建已经改变或依赖关系已经改变的东西？
-
每次推送都会启动一大组生成和许多单元测试，而不仅仅是一个存储库的项目生成和测试。
-
通常在一个或两个存储库中工作的开发人员更喜欢这个新的多存储库世界，并且会拒绝更改回来。
我已经研究了 git 子模块和子树，它们似乎并不能解决我们的许多问题(不确定 Google Repo(。我们中的一些人使用像"mu"这样的工具来提供帮助。如果有一个工具包可以帮助开发人员维护 poms 中的版本，并跟踪存储库中的更改，那就太好了。
如果您有一套用于简化此类环境中开发的过程或工具，请告诉我。
项目都在自己的存储库中(大约 70 个(。
对我来说，这就是问题开始的地方。我的投票赞成大幅减少这个数字。
如果你真的不想要一个存储库(1 个存储库得到了我的投票(，那么你可以使用 1*change_rarely 存储库将代码库分成 n*change_often 个存储库。保持 n 较小很重要。这样，您将避免重建很少更改的位。
此外，即使使用单个存储库，也不需要按源引用所有内容，也不需要将二进制文件用于基本库。当基础库更改时，进行更改的人员也可以一次性更新所有引用，以便所有项目都是最新的。