git多仓协作问题以及解决方案

多仓协作的问题

一个项目可能会由多个代码仓构成。如果这些代码仓之间没有依赖关系，那么除了操作上的不方便，也不会有其他问题。但是， 如果这几个代码仓之间有依赖关系，那么单纯使用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