支持如下两种代码评审模型的代码评审系统
可以按照不同的状态和类型对代码评审进行筛选,并直观的显示评审的各项信息。
可通过下列方式创建代码评审
1、通过评审列表右上角的“创建评审”进行创建MR
2、在线编辑保护分支上的文件,保存时会自动生成临时分支并且创建MR
3、通过分支页面,进行分支合并操作时,自动创建MR
4、通过IDE插件或者Git原生客户端用git push命令向保护分支提交代码,自动生成DCR
5、通过IDE插件或者Git原生客户端通过git push -o dcr命令向非保护分支提交代码,自动生成DCR
评审详情界面显示了该评审相关的所有信息,评审人非常方便的进行行间评论并且在右上角进行总评建议。方便的针对不同的commit进行左右对比评审。
并且提供了关于评审的许多便捷操作,例如全屏、过滤、显示全部等。
此外:评审详情提供了代码视图(默认视图,方便快速进行代码评审),还提供了提交记录、总评讨论视图。
提交记录视图可以方便的查看该评审中的代码commit记录。
总评讨论视图展示了总评建议的给出情况,并且可以方便的向评审人发送评审通知(点击右侧铃铛图标)。
对于DCR,由于没有一个可见的源分支实体,如果评审被打回,想继续修改,继续更新评审可以使用如下方法:
1.评审粒度更细:相对于MR分支合并粒度的评审,动辄数个文件,上千行代码,DCR更适合企业研发场景提倡的少量多次提交,持续集成与交付。
2.工程师使用更便捷:无需登录网页端,直接用IDE原生插件或者Git原生客户端直接即可发起;不用脱离开发环境,导致工作思路中断。
3.企业内开源协同只适合用DCR: MR需要赋予贡献方分支创建与合并、向源分支直接提交代码的权限,故会导致企业的代码安全无法维护;开源协同的PR模式不仅需要Fork代码,导致企业代码到处被复制混乱不堪,而且开源贡献者还需要在新Fork出来的代码库上搭建流水线,从而进一步阻碍其贡献意愿。DCR只需要将企业内需要开源协同的库设置为“公开”类型、企业其他成员即可直接向代码库发起DCR贡献代码(企业其他成员即使向非保护分支提交代码,也会被自动拦截生成DCR)。
在日常开发中,完全可以结合DCR和MR优点共同使用,例如下图示例:
工程师在本地分支开发,频繁使用DCR向远端dev分支提交代码评审;
某feature开发完毕,发起Dev分支向QA分支的MR,通知测试人员提测;
测试人员经过QA分支上的自动化测试及其他测试后,发起从QA分支到Master分支的MR,在Master分支发布版本、上线。
文档内容是否对您有帮助?
评价建议不能为空
非常感谢您的反馈,我们会继续努力做到更好!