# 使用技巧
# 向非保护分支发评审
DCR因为使用便捷，所以在实际研发场景中，广受欢迎。 但是默认情况下使用git push命令只有向保护分支提交代码才会自动生成评审。 如果向非保护分支也希望通过命令行快速发起评审，可以使用如下命令:
$git push -o dcr
# 发DCR评审时自动通知评审人
创建DCR时，可通过-o参数直接想评审人发送通知， 例如如下命令可实现向非保护分支发起DCR的同时，同步向liuqing、zhutiankai两个用户发送评审通知。@符号表示后面是指定评审人列表:
$git push -o dcr -o @liuqing,zhutiankai
# 通过二级目录批量设置权限
通过系统顶部的面包屑导航，可以切换到二级目录设置界面。
二级目录设置为部门或者团队统一管理其代码库权限提供了方便的入口。
# Gitflow与DCR、MR结合使用
完整的Gitflow算是git分支模型中最复杂和严谨的了。 通常在企业研发过程中，都会对Gitflow进行精简。 本例已一个完整Gitflow为例，介绍一个最复杂场景下Gitflow与DCR、MR结合使用。 如下图所示，仅需做如下措施即可：
- 将代码库所有分支均设置为保护分支，所有入库代码都需要评审，作为企业研发规范（实际上业界很多大厂都要求入库代码必须经过评审）
- Gitflow中原有分支合并操作依然使用MR，不变
- 本地向服务器端Feature分支的代码直接提交自动会生成DCR
# 常用的Gitflow简化模型
Gitflow的问题就是分支太多，分支类型也太多，所以常见的方式就是减少分支和分支类型数量 分支的目的是起到隔离的做用，而软件工程讲究持续集成，尽量早的集成，所以每种类型分支的减少，都需要团队具备更强大的持续集成能力。
将Gitflow中的Feature类型分支舍去，其他分支保留 直接通过DCR向Develop分支发起代码评审，其他分支合并使用MR 这个时候就需要团队使用例如Feature开关、后端先行、接口兼容等技术手段弥补Feature分支带来的问题。
只留Master分支 这是一种极端的例子，主干开发，只有团队具有极强的工程能力保障才适合此模型。 工程能力强的团队通过代码评审、Feature开关、超强的自动化测试能力、小流量上线机制等 保障主干代码是高质量可随时上线的，如果有线上问题，可及时回滚。 当然也有团队工程能力一塌糊涂的也搞主干开发的，就是搞的会比较狼狈。
分支开发主干发布模型 主要保留Develop分支、Master分支 通过DCR向Develop分支提交代码，提测后，发起MR合入Master分支，Master测试流水线通过后，发布版本，部署上线。 紧急Bug必须通过Hotfix修复的，Hotfix分支处理方式和Gitflow模型类似。 否则通过回滚或者在下一个版本的开发分支上修复。
主干开发分支发布模型 主要保留Master分支、Release分支 在Master上进行开发，测试和问题修复。问题收敛达到提测要求时，拉出Relase分支，如果Relase分支上的测试通过，则打Tag、部署上线。 否则可以在Release 分支继续进行临时问题修复后上线。
# 集成Sonarqube
如果在ezPipeline的流水线中配置了Sonarqbue代码扫描插件，
则该插件会在扫描结束后将结果推送到该分支的代码浏览页。
点击该结果即可查看代码质量详细报告。
注：该推送结果只会保留最新被推送的结果，新推送数据会覆盖老数据。
