本文主要介绍分支标签评审模式的使用背景，以及如何去使用分支标签评审模式。
使用背景
推送评审采用评审的形式对仓库中的代码变更进行管理，防止代码被随意修改。然而，拥有写权限的用户仍然可以在仓库内创建或删除分支和标签，这可能导致仓库中的分支和标签出现混乱。一个典型的例子是，仓库中可能会存在众多过期且无用的分支，这不仅影响日常维护，还降低了研发效率。通过实施分支和标签的评审，可以有效避免上述问题。即使是具备相应权限的用户，也将不再直接创建或删除分支和标签，而是需创建一个评审，从而有效地以评审的形式管理仓库内分支和标签的变更，满足管理要求。
与代码评审的区别
代码评审主要关注于代码本身的改动，例如在开发新特性或合并分支时，使用代码评审来确保代码合入的质量。分支标签评审主要关注仓库内分支/标签的变更，评审的是变更这一行为，具体包括：
分支操作：
创建一个新分支。
删除已有分支。
重置分支到某一历史提交。
标签操作：
创建一个新标签。
删除已有标签。
重置标签。
如何启用分支标签评审
启用分支标签评审需要新版合并请求的支持，目前新版合并请求正逐步开放中。
在开启了新版合并请求后，在仓库 中，可以看到启用分支标签评审模式的开关。开启开关即可启用分支标签评审，并可进行一系列的配置：
具体说明如下：
评审范围：使用评审范围来指定需要为哪些分支标签启用评审，分支的范围和标签的范围是独立设置的。例如，为分支选择“全部”范围，那么仓库中所有的分支变更都将创建一个评审。也可以选择“指定命名”，使用 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
对应创建出的分支标签评审的效果为：
在页面上操作
在页面端操作时，如果期望变更的分支/标签命中了给定的规则，将无法直接操作而是创建一个分支标签评审，效果如图：
在删除分支时，如果期望删除的分支命中了给定规则，也将无法直接删除，而是创建一个评审，效果如图：
页面上的标签的操作与分支类似。
如何执行分支标签评审
分支标签评审与新版合并请求相似，但去除了代码差异和改动的部分，使用描述信息来描述分支标签的变更。执行分支标签评审需要满足两个条件：
无执行冲突：执行冲突指的是期望变更的分支/标签与当前仓库中的分支/标签存在冲突。例如两个评审都希望创建分支
dev，但其中一个评审先执行成功了，那么另外一个评审就会变为冲突状态，无法执行。达到足够的通过人数：在仓库中，可以为分支标签评审设置需要的最小票数，效果如图：
评审通过后且无冲突，评审将进入待执行状态，单击执行即可以执行评审，创建出
dev分支，效果如图：