不知道开发者们是否都有这样的经历，在我们接受一个开发任务后，需要经历下述流程才可以完成它：
- 本地更新主干，基于主干新建一个分支并切换；
- 进行开发；
- 将这个分支推送到远端；
- 打开 Gitee ，进入创建 Pull Request 界面；
- 选定目标分支；
- 填写 Title 以及 Description；
- 点击提交 Pull Request。
有些同学，尤其是在企业内部进行研发协作的同学，一定觉得这一过程实在是太繁琐了：
「明明任务已经明确了要做的改动以及后续测试用例，为什么我还要再写一次」
「我提交信息写的已经非常详细了，没必要再重新赘述了」
「不能推送就自动给我创建一个 Pull Request，然后自动关联分支相关的任务吗？」
...
那么，有没有一种方法可以快速创建 Pull Request 呢？
答案是： 有！
现在 Gitee 可以设置保护分支为 评审模式，无此分支推送权限的用户，推送后都将自动创建（或者更新）一个 Pull Request。
什么是「评审模式」
为了解决上文中创建 Pull Request 流程繁琐的问题，我们扩展了保护分支，将保护分支分为两种模式：
- 标准模式： 与原有保护分支逻辑一致，严格遵循推送和合并的权限，如无权限，推送将被拒绝。
- 评审模式： 与标准模式唯一不同的一点是，如果用户没有推送权限，那么他的推送将会自动创建（或者更新）一个 Pull Request。
「评审模式」使用案例
在仓库管理-保护分支设置中，该仓库的管理员新增了一个保护分支规则 review，并且设置了它为评审模式以及禁止任何人推送，那么其他仓库成员往review分支推送代码，都会自动创建一个 Pull Request：
如果再次进行提交并推送，那么 Gitee 检测到该用户已经在这个分支被自动创建过一个 Pull Request 了，那么他就会自动更新这个 Pull Request 的代码：
这时前往 Gitee 可以看到自动创建的 Pull Request 以及第二次更新的记录：
如何更高效地使用「评审模式」
评审模式提供的自动创建 Pull Request 虽然方便，但是如果在一个分支来回折腾的话，很可能会把开发者自己玩晕，所以推荐两种使用方式，在解放生产力的同时，还能够有条不紊的进行不同任务的研发。
本地分支开发
本地主干开发
以上就是评审模式的简单介绍，目前已在 Gitee 上全量开放给所有用户，快在团队的代码评审流程中试试吧，更高阶的玩法等你去探索。
猜你喜欢: