Merge Request Approvals

原文：https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html

• Optional Approvals
• Required Approvals
  • Approval Rules
    • Eligible Approvers
      • Implicit Approvers
      • Code Owners as eligible approvers
    • Adding / editing a default approval rule
      • Editing / overriding approval rules per merge request
    • Multiple approval rules
    • Scoped to Protected Branch
  • Adding or removing an approval
  • Merge request approvals project settings
    • Prevent overriding default approvals
    • Resetting approvals on push
    • Allowing merge request authors to approve their own merge requests
    • Prevent approval of merge requests by their committers
    • Require authentication when approving a merge request
  • Security approvals in merge requests
  • Enabling the new approvals interface

Merge Request Approvals

代码审查是每个成功项目的基本实践，一旦合并请求状态良好，就需要您的批准，这是审查过程的重要组成部分，因为它清楚地传达了合并变更的能力.

Optional Approvals

在GitLab Core 13.2 中引入.

具有开发者权限或更高权限的任何用户都可以在 GitLab Core 中批准合并请求. 这为审阅者提供了一种一致的机制来提供批准，并使维护者更容易知道何时可以合并更改. Core 中的批准是可选的，并且在没有批准的情况下不会阻止合并请求的合并.

Required Approvals

在GitLab 企业版 7.12 中引入.

必需的批准通过要求指定的人在可以合并的合并请求之前批准，可以强制执行代码审查.

所需的批准可启用多个用例：

• 强制审查所有合并到存储库中的代码.
• 通过批准规则指定给定提议的代码更改的审核者，以及最少数量的审核者.
• 为所有建议的代码更改指定审阅者的类别，例如后端，前端，质量保证，数据库等.
• 由合并请求中更改的文件确定，自动将代码所有者指定为合格的批准者 .
• 在合并可能引入漏洞的代码之前， 需要获得安全团队的批准 .

Approval Rules

批准规则定义了合并请求在可以合并之前必须获得多少个批准，以及可选地应该由哪些用户进行批准. 可以定义批准：

• As project defaults.
• Per merge request.

如果未定义批准规则，则任何用户都可以批准合并请求，尽管仍可以在项目设置中为合并请求批准设置所需批准者的默认最小数量.

批准规则定义了合并请求在可以合并之前必须获得多少个批准，以及可选地应该由哪些用户进行批准. 可以定义批准：

• As project defaults.
• Per merge request.

如果未定义批准规则，则任何用户都可以批准合并请求，尽管仍可以在项目设置中为合并请求批准设置所需批准者的默认最小数量.

Eligible Approvers

以下用户可以批准合并请求：

• 在项目中被添加为批准者的用户，或将请求级别与开发者或更高权限合并的用户 .
• 由合并请求更改的具有开发人员或更高权限的文件的代码所有者 .

如果单个用户是以下成员的成员，则可以将其添加为项目的批准者：

• 该项目.
• 该项目的直接上级组.
• 可以通过共享访问项目的组.

也可以将一组用户添加为批准者. 将来，小组批准者可能只限于对项目具有共享访问权限的小组 .

如果将用户添加为个人批准者，并且也是组批准者的一部分，则该用户仅被计数一次. 如果在项目设置上启用了” 阻止作者批准” （默认情况下启用）和” 阻止提交者批准” （默认情况下禁用），则合并请求作者以及已提交合并请求的用户均不算作合格批准者.

Implicit Approvers

如果所需批准的数量大于分配的批准者的数量，则来自其他用户的批准将计入满足要求. 这些将是在项目中具有开发人员权限或更高权限的用户，但未在批准规则中明确列出.

Code Owners as eligible approvers

Introduced in GitLab Starter 11.5.

如果将代码所有者添加到存储库中，则相应文件的所有者将与具有 Developer 或更高权限的成员一起成为合格的批准者.

要启用此合并请求批准规则：

1. 导航到项目的“设置”>”常规”，然后展开” 合并请求批准” .
2. 找到任何合格的用户，然后选择所需的批准数量.

设置后，合并请求只能在您设置的批准数量批准后才能合并. manbetx 客户端打不开将毫无区别地接受来自具有开发者或更高权限的用户以及代码所有者的批准.

或者，您可以要求 保护所有者的代码所有者批准 .

Adding / editing a default approval rule

要添加或编辑默认的合并请求批准规则：

1. 导航到您项目的 设置>常规，然后展开合并请求批准 .

2. 单击添加批准规则 ，或单击编辑 .

   • 添加或更改规则名称 .
   • 设置所需的批准号所需的批准数量. 最小值是0 .
   • （可选）搜索有资格批准合并请求的用户或组，然后单击” 添加”按钮将其添加为批准者. 在搜索字段中键入之前，将根据合并请求更改的文件的先前作者来建议批准者.
   • （可选）点击 组或用户旁边的” 删除”按钮可将其从规则中删除.
3. Click 添加批准规则 or 更新批准规则.

在更改规则之前创建的任何合并请求都不会更改. 他们将保留原始批准规则，除非手动覆盖 .

注意：如果合并请求的目标是其他项目，例如从分支到上游项目，则默认批准规则将从目标（上游）项目而不是源（叉子）获取.

Editing / overriding approval rules per merge request

在 GitLab 企业版 9.4 中引入.

默认情况下，MR 作者或具有足够权限的用户可以编辑每个合并请求（MR）中列出的合并请求批准规则. 可以在合并请求批准设置中禁用此功能.

一种可能的情况是添加比默认设置中定义更多的批准者.

创建或编辑合并请求时，请找到” 批准规则”部分，然后按照与添加/编辑默认批准规则相同的步骤进行操作.

Multiple approval rules

Introduced in GitLab Premium 11.10.

在 GitLab Premium 中，每个合并请求可以有多个批准规则，每个项目可以有多个默认批准规则.

添加或编辑多个默认规则与添加或编辑单个默认批准规则相同 ，不同之处在于，即使已经定义了规则，” 添加批准规则”按钮仍可用于添加更多规则.

同样，每个合并请求中编辑或覆盖多个批准规则与每个合并请求中编辑或覆盖批准规则相同，只是即使已定义一个规则，” 添加批准规则”按钮仍可用于添加更多规则.

当合格的批准人批准合并请求时，它将减少批准人所属的所有规则的剩余批准数.

Scoped to Protected Branch

Introduced in GitLab Premium 12.8.

批准规则通常仅与特定分支（例如master . 在配置默认批准规则时，可以通过导航到项目的“设置” ，展开” 合并请求批准” ，然后从” 目标”分支下拉列表中选择” 任何”分支 ，将这些作用域一下子作用于所有受保护的分支.

或者，您可以从” 目标”分支下拉列表中选择一个非常特定的受保护分支：

要启用此配置，请参阅代码所有者对受保护分支的批准 .

Adding or removing an approval

当合格的批准者访问一个开放合并请求时，可能是以下之一：

• 如果所需的批准数目尚未满足，他们可以通过点击批准它显示的批准按钮.

  

• 如果已经满足所需的批准数量，则他们仍然可以通过单击显示的“额外批准”按钮来批准 .

  

• 他们已经批准了此合并请求 ：他们可以删除他们的批准.

  

注意：如果在项目设置中启用了” 阻止作者批准”，则不允许合并请求作者批准自己的合并请求.

满足批准规则后，如果没有其他阻止请求，则可以合并合并请求. 请注意，合并请求仍可能被其他条件阻止，例如合并冲突， 挂起的讨论或失败的 CI / CD 管道 .

Merge request approvals project settings

可以通过以下步骤找到合并请求批准的项目设置： 设置>常规和扩展合并请求批准 .

Prevent overriding default approvals

默认情况下，用户可以在合并请求中编辑批准规则. 如果禁用，则所有新合并请求的批准规则将由默认批准规则确定. 要禁用此功能：

1. 取消选中可以覆盖每个合并请求所需的批准人和批准复选框.
2. Click 保存更改.

Resetting approvals on push

当新的提交被推送到合并请求的源分支时，您可以强制删除对合并请求的所有批准. 如果禁用，则即使合并请求中添加了更改，批准也将持续. 要启用此功能：

1. Check the 将新提交推送到其源分支时，删除合并请求中的所有批准 checkbox.
2. Click 保存更改.

注意：重新定义来自 UI 的合并请求时，批准不会重置. 但是，如果更改了目标分支，则批准将被重置.

Allowing merge request authors to approve their own merge requests

Introduced in GitLab Starter 11.3.

您可以允许合并请求作者自行批准合并请求. 作者也必须包含在批准者列表中，以便能够批准其合并请求. 要启用此功能：

1. 取消选中” 阻止合并请求作者批准合并请求”复选框，默认情况下启用此复选框.
2. Click 保存更改.

Prevent approval of merge requests by their committers

Introduced in GitLab Starter 11.10.

您可以阻止已提交合并请求的用户批准它. 要启用此功能：

1. 选中阻止提交者批准合并请求复选框.
2. Click 保存更改.

Require authentication when approving a merge request

Introduced in GitLab Starter 12.0.

注意：要在批准合并请求时要求身份验证，必须在登录限制下启用为 Web 界面启用的密码身份验证 . 在管理区域中.

您可以强制批准者输入密码以进行身份​​验证，然后再添加批准. 这使电子签名能够获得批准，例如CFR Part 11所定义的签名. 要启用此功能：

1. 选中需要用户密码批准复选框.
2. Click 保存更改.

Security approvals in merge requests

可以将合并请求批准配置为在合并请求引入漏洞时需要安全团队成员的批准.

有关更多信息，请参见合并请求中的安全性批准 .

Enabling the new approvals interface

从GitLab v12.0 开始 ，默认情况下会提供更新的批准界面. 在 12.0 之前的版本中，除非启用了approval_rules功能标志，否则更新的界面不可用，这可由实例管理员从 Rails 控制台中完成.

使用以下命令来启动 Rails 控制台：

# Omnibus GitLab
gitlab-rails console
# Installation from source
cd /home/git/gitlab
sudo -u git -H bin/rails console -e production

然后运行Feature.enable(:approval_rules)以启用更新的界面.