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

刺猬窝窝头 · · 1252 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

多仓协作的问题

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

有疑问加站长微信联系(非本文作者)

本文来自:简书

感谢作者:刺猬窝窝头

查看原文:git多仓协作问题以及解决方案

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

1252 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传