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

2023-06-28 17:56:32 +08:00
 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 自动创建)

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

787 次点击
所在节点    问与答
1 条回复
HuskyYellow
2023-06-29 10:09:11 +08:00
我也想过这个事,但是有个问题,每次拉代码都要去拉一遍子仓库的代码,还有个问题是如果子项目过多,其实维护起来还是没有一个项目方便的。除非子仓库更新频率不高。 以上仅个人建议。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/952467

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX