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