现在 Gitee 可以设置保护分支为 评审模式,之后任何无权限推送到此分支的推送,都将自动创建(或者更新)一个 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
「往评审模式的保护分支上推送的 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 虽然方便,但是如果在一个分支来回折腾的话,很可能会把开发者自己玩晕,所以推荐两种使用方式,在解放生产力的同时,还能够有条不紊不同任务的研发。
一、本地分支开发
二、本地主干开发
快来体验吧!