多仓协作的问题
一个项目可能会由多个代码仓构成。如果这些代码仓之间没有依赖关系，那么除了操作上的不方便，也不会有其他问题。但是， 如果这几个代码仓之间有依赖关系，那么单纯使用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工作流的变化，由原先典型的分布式工作流，变为了集中式工作流； 这一点的变化可能对提交门禁和流水线有影响。 下面附一张对比图。
slide-13.jpg
网友评论