个中缘由就不展开了。现在领导提出新的要求，要把单体仓库拆分成每个组件独立的仓库，来实现对代码权限的细分。
但这种 multi repo 的形式对 CI 构建打包造成了很大的挑战：由于我们的微服务架构是假微服务，实际上某些组件之间是有强依赖的，当某个新特性开发时，相关组件都需要一起刷版本，才能实现正确的功能，否则会因为接口对不上之类的情况而不能正常工作。
由于 gitlab 的 CI 对于跨库的 pipeline 支持较弱，只能通过 trigger 下游的方式来创建关联性；这在 multi repo 数量越来越多的情况下是灾难性的。
所以我们想为 CI 创建一个 MonoRepo ，由权限较高的用户来控制，它可以以 submodule 的方式把所有子仓库都收集到一起，然后在这个仓库中定义 CI Pipeline 就比较清晰。
submodule 方式也有它的弊端——子仓库的一项变动，提交到主仓库时，仅仅表现为一个 commit id 的变化。这中间如果有操作失误，或者别的错误合入，主仓库的管理者是不容易察觉的。
所以我们想用 git subtree 的方式来建立这个主仓库，在这个形式下，每个子库的代码会直接以实体文件存在于主仓库中，改动提过来也会是代码形式的改动。
已知的缺点就是，主仓库只有高权限用户可见，所以变更提交也得由高权限用户发起，相当于领导自己提 MR 自己审。（但这个缺点在 submodule 方案中也存在）
如果有多项任务并行在开发，容易发生冲突吗？
（因为我们察觉到 subtree 合并时发生的冲突解决起来比较麻烦，如果在主仓库解决了，主仓库代码就跟子仓库脱节了，所以得回子仓库去解决）
