跳到主要内容

保护分支和保护分支的评审模式

如何设置保护分支​

「保护分支」是 Gitee 针对团队协作中代码权限管理的功能，即为了减小成员误操作带来的损失，对一些关键的分支进行保护，防止被破坏。保护以后，只有仓库的管理员才能对这个分支进行修改、合并等操作。

进入仓库里，代码 -> 分支 -> 保护分支，即可开启保护分支。

输入图片说明

输入图片说明

现在 Gitee 可以设置保护分支为 评审模式，之后任何无权限推送到此分支的推送，都将自动创建（或者更新）一个 Pull Request。

不知道各位开发同学是不是都有这样的经历，在我们接收到一个任务后，需要经历下述流程才可以完成这个任务：

  1. 本地更新主干，基于主干新建一个分支并切换
  2. Coding...
  3. 将这个分支推送到远端
  4. 打开 Gitee，进入创建 Pull Request 界面
  5. 选定目标分支
  6. 填写 Title 以及 Description
  7. 点击提交 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 虽然方便，但是如果在一个分支来回折腾的话，很可能会把开发者自己玩晕，所以推荐两种使用方式，在解放生产力的同时，还能够有条不紊不同任务的研发。

一、本地分支开发

输入图片说明

二、本地主干开发

输入图片说明

快来体验吧！