评审

评审的类型

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

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

评审列表

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

评审创建

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

评审详情

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


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


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

DCR的更新

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

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

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

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分支发布版本、上线。