用 git subtree 来实现 Monorepo 是个好主意吗？

[twistedmeadows]

我们的系统是一个假的微服务架构，虽然有很多微服务组件，但实际需要把所有微服务都打包到一起来安装和部署。

个中缘由就不展开了。现在领导提出新的要求，要把单体仓库拆分成每个组件独立的仓库，来实现对代码权限的细分。

但这种 multi repo 的形式对 CI 构建打包造成了很大的挑战：由于我们的微服务架构是假微服务，实际上某些组件之间是有强依赖的，当某个新特性开发时，相关组件都需要一起刷版本，才能实现正确的功能，否则会因为接口对不上之类的情况而不能正常工作。

由于 gitlab 的 CI 对于跨库的 pipeline 支持较弱，只能通过 trigger 下游的方式来创建关联性；这在 multi repo 数量越来越多的情况下是灾难性的。

所以我们想为 CI 创建一个 MonoRepo ，由权限较高的用户来控制，它可以以 submodule 的方式把所有子仓库都收集到一起，然后在这个仓库中定义 CI Pipeline 就比较清晰。

各微服务组件有自己独立的仓库，可以在上面自由开发，每周或每个特性再提一笔 MR 到 MonoRepo 来，使主仓库集成该改动。基于 MR 可以触发整个系统的打包，供测试取用。

• 进入正题

submodule 方式也有它的弊端——子仓库的一项变动，提交到主仓库时，仅仅表现为一个 commit id 的变化。这中间如果有操作失误，或者别的错误合入，主仓库的管理者是不容易察觉的。

所以我们想用 git subtree 的方式来建立这个主仓库，在这个形式下，每个子库的代码会直接以实体文件存在于主仓库中，改动提过来也会是代码形式的改动。

已知的缺点就是，主仓库只有高权限用户可见，所以变更提交也得由高权限用户发起，相当于领导自己提 MR 自己审。（但这个缺点在 submodule 方案中也存在，我们可以为它调整研发流程，例如用 bot 自动创建）

• 想问下有没有实践过这种方案（ git subtree 实现 Monorepo ）的团队？用起来怎么样？

如果有多项任务并行在开发，容易发生冲突吗？ （因为我们察觉到 subtree 合并时发生的冲突解决起来比较麻烦，如果在主仓库解决了，主仓库代码就跟子仓库脱节了，所以得回子仓库去解决）

[HuskyYellow]

我也想过这个事，但是有个问题，每次拉代码都要去拉一遍子仓库的代码，还有个问题是如果子项目过多，其实维护起来还是没有一个项目方便的。除非子仓库更新频率不高。 以上仅个人建议。