多仓协作的问题
一个项目可能会由多个代码仓构成。如果这些代码仓之间没有依赖关系,那么除了操作上的不方便,也不会有其他问题。但是, 如果这几个代码仓之间有依赖关系,那么单纯使用git管理就会存在问题。
例如有两个代码仓,代码仓A是功能源码仓,代码仓B是测试用例仓。 那么,代码仓B的特性用例集B‘的执行,就依赖于代码仓A对应特性A’的功能代码提交; 只有同时提交或者已经提交了,相关用例才能够成功执行。现在问题来了, 要追溯一些历史问题,怎么样才能够使得两个代码仓都回退到一个匹配的提交点上,使得源代码和测试用例是匹配的?
解决方案
目前知道几种解决方案:
- git submodule
- git subtree
- google repo/manifest
- git mm/manifest
各个解决方法都有自己的特点和适用场景。
git submodule
有如下特点:
- 代码仓有主次之分,子仓是作为主仓的一个目录或者模块存在的。
- 通过子目录以及下面的.submodule文件来进行关联主仓与子仓。
- 主仓的提交历史与子仓的提交历史是独立的,各自有各自的时间线。
主要缺点:
- 使用git submodule命令来管理子仓,无法同时操作主仓和子仓。 当子仓数目较大时,命令敲得有些发麻。
- 多人开发时,容易犯错, 不太容易记得去不停地更新子仓目录,可能有覆盖写的风险。
- 主仓与子仓之间的关联性管理弱,无法快捷地将所有仓回退到某个匹配的提交点上。
适用场景:
- 主仓与子仓没有依赖性;
- 主仓仅仅是调用子仓的功能,二者在提交上没有功能依赖性;
git subtree
有如下特点:
- 代码仓有主次之分,子仓是作为主仓的一个目录或者模块存在的。
- 通过目录节点和元信息来进行关联主仓与子仓。
- 子仓的提交历史会体现主仓中, 同时也存在于自身的代码仓中。
- 使用git subtree命令来进行管理操作。
主要优点:
- 将主仓和所有子仓的提交历史排在一条时间线上,不再是独立的多个时间线。 可以快速回退到某个同步的提交点上。
- 子仓的存在对于开发人员是透明的, 操作时感觉到仅仅主仓存在。
主要缺点:
- 所有子仓的提交历史都会出现在主仓上,会加速主仓的膨胀。从空间上看, 本质是将所有代码仓合为一个代码仓。
- git subtree命令操作同样比较复杂一些,学习成本高。
适用场景:
- 主仓与子仓存在依赖性。
- 其他资料表明,此种方法适用了子仓一写多读的、订阅式的组件共享场景。
Google repo/manifest
主要特点是:
- 使用额外的manifest仓来管理多个代码仓。
- 使用superMR来存储和管理多个代码仓之间的提交关联性, 支持任意提交点的同步回滚。
- 开发过程中可批量操作子仓,与git submodule跳转到各个子仓下面进行git命令操作相比,更方便快捷、容易上手。
- 需要使用工具repo管理操作。
- Google repo是使用Python脚本写的。
可以使用repo/manifest来解决有依赖关系的多仓协作的问题。
git mm/manifest
与Google repo/manifest相似, 解决问题的场景也是相同的。不同点在于, git mm是华为内部研发的, 使用golang开发的。
这一工具同时也带来了git工作流的变化,由原先典型的分布式工作流,变为了集中式工作流; 这一点的变化可能对提交门禁和流水线有影响。 下面附一张对比图。
有疑问加站长微信联系(非本文作者)