保护分支和保护分支的评审模式
如何设置保护分支
「保护分支」是 Gitee 针对团队协作中代码权限管理的功能,即为了减小成员误操作带来的损失,对一些关键的分支进行保护,防止被破坏。保护以后,只有仓库的管理员才能对这个分支进行修改、合并等操作。
进入仓库里,代码 -> 分支 -> 保护分支,即可开启保护分支。
现在 Gitee 可以设置保护分支为 评审模式,之后任何无权限推送到此分支的推送,都将自动创建(或者更新)一个 Pull Request。
不知道各位开发同学是不是都有这样的经历,在我们接收到一个任务后,需要经历下述流程才可以完成这个任务:
- 本地更新主干,基于主干新建一个分支并切换
- Coding...
- 将这个分支推送到远端
- 打开 Gitee,进入创建 Pull Request 界面
- 选定目标分支
- 填写 Title 以及 Description
- 点击提交 Pull Request
这个时候有一些同学就觉得繁琐了:
- 「明明任务已经明确了要做的改动以及后续测试用例,为什么我还要再写一次」
- 「我提交信息写的已经非常详细了,没必要再重新赘述了」
- 「不能推送就自动给我创建一个 Pull Request,然后自动关联分支相关的任务吗?」
- ...
那么,有没有一种方法可以快速创建 Pull Request 呢?
答案是: 可以!
保护分支的评审模式
新功能介绍:保护分支的评审模式
为了解决上面创建 Pull Request 繁琐的问题,我们扩展了保护分支,将保护分支分为两种模式:
- 标准模式:与原有保护分支逻辑一致,严格遵循推送和合并的权限,如无权限,推送将被拒绝
- 评审模式: 与标准模式唯一不同的一点 -> 如果用户没有推送权限,那么他的推送将会自动创建(或者更新)一个 Pull Request
这里我在 仓库管理 - 保护分支设置 ,新增了一个保护分支规则review
,并且设置了它为评审模式以及禁止任何人推送,那么无论是谁(前提当然得是仓库成员啦)往review
分支推送代码,都会自动创建一个 Pull Request:
可 以看到,服务端发现review
分支是一个评审模式的保护分支,并且我没有权限推送到这个分支(因为设置了禁止任何人推送),Gitee 就自动把我推送的提交向review
分支创建了一个 Pull Request,并且给出了地址访问。
如果我再进行了一次提交,并且再次推送,那么 Gitee 检测到我已经在这个分支被自动创建过一个 Pull Request 了,那么他就会帮我自动更新这个 Pull Request 的代码:
这时我们前往 Gitee 可以看到自动创建的这个 Pull Request 已经被更新了
另外,您还可以直接通过更新自动创建的那个源分支的方式进行 Pull Request 的更新,也就是我们上面自动创建的auto-62561-review-1625833887273
分支,具体步骤如下
git fetch
git checkout auto-62561-review-1625833887273
// Coding...
git add {xxfile}
git commit -m "update auto pr"
git push origin auto-62561-review-1625833887273
自动创建&更新 Pull Request 规则
「往评审模式的保护分支上推送的 Commit 必须是完全包含某个 Pull Request 的差异 Commit 才可以更新这个 Pull Request,否则就新建一个 Pull Request」,这句话看起来非常拗口,下面我们详细列出自动创建和更新 Pull Request 各种场景,这样我们才能建立起使用评审模式的正确姿势。
我们做如下约定
remote
表示远端local
表示本地result
表示结果1-2-3-4
表示有四个提交,最新的为4
PR 表示 Pull Request
我们约定远程现在有四个提交:remote: 1-2-3-4
Case1
local: 1-2-3-4-5
result: Created PR-a 包含 5
Case2
local: 1-2-3-4-5-6
result: Updated PR-a 包含 5-6(因为已经有 PR,并且本次版本是这个 PR 差异的父集,所以更新即可)
Case3
local: 1-2-3-4-5-7 修改了提交 6,变成了提交 7 (revert 或者 commit --amend 操作)
result: Created PR-b 包含 5-7(已经有的 PR 并不是本次版本的子集,本次版本不包含 6,故而创建一个 PR)
推荐的使用姿势
评审模式提供的自动创建 Pull Request 虽然方便,但是如果在一个分支来回折腾的话,很可能会把开发者自己玩晕,所以推荐两种使用方式,在解放生产力的同时,还能够有条不紊不同任务的研发。
一、本地分支开发
二、本地主干开发
快来体验吧!