产品术语

DCR

DCR(Direct code review) 是ezCode的专利技术，当对保护分支进行git push操作时，自动创建代码评审。 具体参考如下截图：

DCR的更新

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

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

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

DCR特点

• 代码评审粒度更小、更适合企业协同 代码评审提倡小粒度，一般以不超过400行diff代码为宜， 否则对于评审人来说是一场噩梦。 相对于MR，在一个分支上把功能开发完成后再发代码评审，DCR更适合用于代码评审，尤其是企业内代码评审场景。 MR本身来源于Github的开源协同PR(Pull request)模型，更适合开源或者弱协同（例如团队非常成熟，个顶个都是一流高手）场景。

• 更方便，开发效率更高 可以直接使用Git原生命令、IDE Git原生插件实现，不用登录ezCode网页去点击创建MR； 无需创建临时分支、所以也无需MR合入后删除临时分支等一系列操作；

• 更方便企业进行内部开源协同 企业内部开源协同作为提升企业协同效率的方法，受到越来越多企业的青睐。 但是如果像Github那样进行fork，则会导致企业代码库被到处复制，治理混乱。 如果像Gitlab那样只有MR模型，那就需要给企业所有成员开代码库写权限，否则无法创建临时分支，无法向临时分支提交代码，无法发起MR，权限管理安全风险大。 但是如果使用ezCode, 则只需要把代码库类型设置为公开，这样企业内所有成员都具有了读权限，他们通过DCR方式向目标分支发起代码评审即可。 代码库的评审和写入权限依然控制在少数代码库成员中。

• DCR的缺点：只有一个，就是向保护分支通过dcr的方式直接push代码时候，会被远程Git server拦截，并自动创建一个代码评审单。 Git客户端会显示一个提交失败的Error，不了解dcr的用户会在刚刚使用的时候有点困惑

DCR和MR结合使用

在日常开发中，完全可以结合DCR和MR优点共同使用，例如下图示例：

• 工程师在本地分支开发，频繁使用DCR向远端dev分支提交代码评审；
• 某feature开发完毕，发起Dev分支向QA分支的MR，通知测试人员提测；
• 测试人员经过QA分支上的自动化测试及其他测试后，发起从QA分支到Master分支的MR，在Master分支发布版本、上线。

MR

MR(Merge request) 是分支合并请求的简称。 MR是进行代码评审，提升代码质量的一种常见方法。 具体是指创建一个从源分支A到目标分支B的MR进行代码评审，在评审通过后合入。