评审

最近更新时间:2021-01-19 12:01:55

查看PDF

评审的类型

支持如下两种代码评审模型的代码评审系统

  1. MR(Merge request)业界典型的分支合并模型
  2. DCR(Direct code review) 直接代码评审,提交代码自动生成评审,无需特殊客户端、无需特殊命令。例如下图:

image.png

评审列表

可以按照不同的状态和类型对代码评审进行筛选,并直观的显示评审的各项信息。

image.png

评审创建

可通过下列方式创建代码评审
1、通过评审列表右上角的“创建评审”进行创建MR
2、在线编辑保护分支上的文件,保存时会自动生成临时分支并且创建MR
3、通过分支页面,进行分支合并操作时,自动创建MR
4、通过IDE插件或者Git原生客户端用git push命令向保护分支提交代码,自动生成DCR
5、通过IDE插件或者Git原生客户端通过git push -o dcr命令向非保护分支提交代码,自动生成DCR

评审详情

评审详情界面显示了该评审相关的所有信息,评审人非常方便的进行行间评论并且在右上角进行总评建议。方便的针对不同的commit进行左右对比评审。
并且提供了关于评审的许多便捷操作,例如全屏、过滤、显示全部等。
此外:评审详情提供了代码视图(默认视图,方便快速进行代码评审),还提供了提交记录、总评讨论视图。

image.png
提交记录视图可以方便的查看该评审中的代码commit记录。

image.png
总评讨论视图展示了总评建议的给出情况,并且可以方便的向评审人发送评审通知(点击右侧铃铛图标)。

image.png

DCR的更新

对于DCR,由于没有一个可见的源分支实体,如果评审被打回,想继续修改,继续更新评审可以使用如下方法:

  1. 在本地开发环境上直接修改,直接push,非常简单。系统会自动识别并更新当前评审。

    image.png

  2. 如果更换了电脑,失去了开发环境,则可以通过评审详情页面先将代码fetch到本地,然后修改编辑后提交即可。

    image.png

DCR的特点

1.评审粒度更细:相对于MR分支合并粒度的评审,动辄数个文件,上千行代码,DCR更适合企业研发场景提倡的少量多次提交,持续集成与交付。
2.工程师使用更便捷:无需登录网页端,直接用IDE原生插件或者Git原生客户端直接即可发起;不用脱离开发环境,导致工作思路中断。
3.企业内开源协同只适合用DCR: MR需要赋予贡献方分支创建与合并、向源分支直接提交代码的权限,故会导致企业的代码安全无法维护;开源协同的PR模式不仅需要Fork代码,导致企业代码到处被复制混乱不堪,而且开源贡献者还需要在新Fork出来的代码库上搭建流水线,从而进一步阻碍其贡献意愿。DCR只需要将企业内需要开源协同的库设置为“公开”类型、企业其他成员即可直接向代码库发起DCR贡献代码(企业其他成员即使向非保护分支提交代码,也会被自动拦截生成DCR)。

DCR和MR结合

在日常开发中,完全可以结合DCR和MR优点共同使用,例如下图示例:
工程师在本地分支开发,频繁使用DCR向远端dev分支提交代码评审;
某feature开发完毕,发起Dev分支向QA分支的MR,通知测试人员提测;
测试人员经过QA分支上的自动化测试及其他测试后,发起从QA分支到Master分支的MR,在Master分支发布版本、上线。
image.png

文档内容是否对您有帮助?

根本没帮助
文档较差
文档一般
文档不错
文档很好

在文档使用中是否遇到以下问题

内容不全,不深入
内容更新不及时
描述不清晰,比较混乱
系统或功能太复杂,缺乏足够的引导
内容冗长

更多建议

0/200

评价建议不能为空

提交成功!

非常感谢您的反馈,我们会继续努力做到更好!

问题反馈