分支标签评审模式

推送评审使用评审的形式来对仓库中的代码变更进行管理，避免了代码被随意修改，但拥有写权限的用户仍然可以在仓库内创建/删除分支或标签。久而久之，仓库中的分支和标签会越来越混乱。一个典型的例子就是仓库中会存在许多过期无用的分支，既影响日常的维护，也降低了研发效率。

使用分支标签评审，可以有效避免以上问题。即使是具有相应权限的用户也将不再能直接创建/删除分支和标签，而是转而创建一个评审，有效地将仓库内分支/标签的变更以评审的形式管理起来，达成管控诉求。

与代码评审的区别

代码评审主要关注于代码本身的改动，例如在开发新特性或合并分支时，使用代码评审来确保代码合入的质量。分支标签评审主要关注仓库内分支/标签的变更，评审的是变更这一行为，具体包括：

• 创建一个新分支

• 删除已有分支

• 重置分支到某一历史提交

• 创建一个新标签

• 删除已有标签

• 重置标签

如何启用分支标签评审

启用分支标签评审需要新版合并请求的支持，目前新版合并请求正逐步开放中。

在开启了新版合并请求后，在 仓库设置 - 推送规则设置 中，可以看到启用分支标签评审的开关。开启开关即可启用分支标签评审，并可进行一系列的配置，效果如图：

具体说明如下：

• 使用评审范围来指定需要为哪些分支标签启用评审，分支的范围和标签的范围是独立设置的。例如，为分支选择“全部”范围，那么仓库中所有的分支变更都将会创建一个评审。也可以选择“指定命名”，使用 glob 通配符，来为指定的分支开启评审。glob 通配符的基本规则如下：

  • ?匹配单个字符（不包括/）

  • *匹配单级路径下的多个字符

  • **匹配多级路径

  • 具体规则请参考： glob

• 使用允许通过的评审人来选择哪些权限的用户可以通过分支标签评审。

• 设置评审通过的最小人数来控制一个分支标签需要几人评审为通过。

• 选择默认评审人来为分支标签评审添加默认的评审人。

• 设置允许执行评审权限来选择哪些权限的用户可以执行分支标签评审。

如何创建分支标签评审

在命令行操作

开启了分支标签评审后，在命令行推送的改动中，命中给定规则的分支/标签的变更将会自动创建分支标签评审，代码的更新不受影响。例如，一个仓库中已有分支dev和标签v1。以下的命令期望创建新分支feat，创建新分支new-feat，删除标签v1，删除分支dev，更新分支master：

$ git push origin feat:feat new-feat:new-feat :refs/tags/v1 head:master :dev

执行的结果如下，可以看到master分支正常更新了，并为其余分支标签变更创建了一个分支标签评审：

$ git push origin feat:feat new-feat:new-feat :refs/tags/v1 head:master :dev
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 12 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 321 bytes | 321.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: +---------------------------------------------------------------------------+
remote: | The following tips are provided by Codeup:                                |
remote: +---------------------------------------------------------------------------+
remote: | A ref review has been created, please visit:                              |
remote: | https://codeup.aliyun.com/<org-id>/demo/change/1                          |
remote: +---------------------------------------------------------------------------+
To https://codeup.aliyun.com/<org-id>/demo.git
 - [deleted]               refs/changes/1/head
   0e18264b7d..a60d5d32ab  head -> master
 - [deleted]               refs/changes/1/head
 * [new reference]         feat -> refs/changes/1/head
 * [new reference]         new-feat -> refs/changes/1/head

对应创建出的分支标签评审的效果为：

在页面上操作

在页面端操作时，如果期望变更的分支/标签命中了给定的规则，将无法直接操作而是创建一个分支标签评审，效果如图：

在删除分支时，如果期望删除的分支命中了给定规则，也将无法直接删除，而是创建一个评审，效果如图：

页面上的标签的操作与分支类似。

如何执行分支标签评审

分支标签评审与新版合并请求相似，但去除了代码差异和改动的部分，使用描述信息来描述分支标签的变更。

执行分支标签评审需要满足两个条件：

1. 无执行冲突。执行冲突指的是期望变更的分支/标签与当前仓库中的分支/标签存在冲突。例如两个评审都希望创建分支feat，但其中一个评审先执行成功了，那么另外一个评审就会变为冲突状态，无法执行。

2. 达到足够的通过人数。在 仓库设置 - 推送规则设置 中，可以为分支标签评审设置需要的最小票数，效果如图：

评审通过后且无冲突，那么评审将进入待执行状态，点击执行即可以执行评审，创建出feat分支，效果如图：