我的书签
添加书签
移除书签Merge Request Approvals
Merge Request Approvals
代码审查是每个成功项目的基本实践，一旦合并请求状态良好，就需要您的批准，这是审查过程的重要组成部分，因为它清楚地传达了合并变更的能力.
具有开发者或更高权限的任何用户都可以在 GitLab Core 中批准合并请求. 这为审阅者提供了一种一致的机制来提供批准，并使维护者更容易知道何时可以合并更改. Core 中的批准是可选的，并且在没有批准的情况下不会阻止合并请求的合并.
Required Approvals
必需的批准通过要求指定的人在可以合并的合并请求之前批准，可以强制执行代码审查.
所需的批准可启用多个用例：
- 强制审查所有合并到存储库中的代码.
- 通过指定给定提议的代码更改的审核者，以及最少数量的审核者.
- 为所有建议的代码更改指定审阅者的类别，例如后端，前端，质量保证，数据库等.
- 由合并请求中更改的文件确定，自动将代码所有者指定 .
- 在合并可能引入漏洞的代码之前， 需要获得安全团队的批准 .
批准规则定义了合并请求在可以合并之前必须获得多少个批准，以及可选地应该由哪些用户进行批准. 可以定义批准：
如果未定义批准规则，则任何用户都可以批准合并请求，尽管仍可以在所需批准者的默认最小数量.
批准规则定义了合并请求在可以合并之前必须获得多少个批准，以及可选地应该由哪些用户进行批准. 可以定义批准：
如果未定义批准规则，则任何用户都可以批准合并请求，尽管仍可以在项目设置中为合并请求批准设置所需批准者的默认最小数量.
Eligible Approvers
以下用户可以批准合并请求：
- 在项目中被添加为批准者的用户，或将请求级别与开发者或更高权限合并的 .
如果单个用户是以下成员的成员，则可以将其添加为项目的批准者：
- 该项目.
- 该项目的直接上级组.
- 可以通过共享访问项目的组.
也可以将一组用户添加为批准者. 将来，小组批准者可能只 .
如果将用户添加为个人批准者，并且也是组批准者的一部分，则该用户仅被计数一次. 如果在项目设置上启用了” 阻止作者批准” （默认情况下启用）和” （默认情况下禁用），则合并请求作者以及已提交合并请求的用户均不算作合格批准者.
Implicit Approvers
如果所需批准的数量大于分配的批准者的数量，则来自其他用户的批准将计入满足要求. 这些将是在项目中具有开发人员或更高权限的用户，但未在批准规则中明确列出.
Code Owners as eligible approvers
Introduced in 11.5.
如果将代码所有者添加到存储库中，则相应文件的所有者将与具有 Developer 或更高成员一起成为合格的批准者.
要启用此合并请求批准规则：
- 导航到项目的“设置”>”常规”，然后展开” 合并请求批准” .
- 找到任何合格的用户，然后选择所需的批准数量.
设置后，合并请求只能在您设置的批准数量批准后才能合并. manbetx 客户端打不开将毫无区别地接受来自具有开发者或更高权限的用户以及代码所有者的批准.
或者，您可以要求 .
Adding / editing a default approval rule
导航到您项目的 设置>常规，然后展开合并请求批准 .
单击添加批准规则 ，或单击编辑 .
- 添加或更改规则名称 .
- 设置所需的批准号所需的批准数量. 最小值是 .
- （可选）搜索有合并请求的用户或组，然后单击” 添加”按钮将其添加为批准者. 在搜索字段中键入之前，将根据合并请求更改的文件的先前作者来建议批准者.
- （可选）点击 组或用户旁边的” 删除”按钮可将其从规则中删除.
- Click 添加批准规则 or 更新批准规则.
在更改规则之前创建的任何合并请求都不会更改. 他们将保留原始批准规则，除非手动覆盖 .
注意：如果合并请求的目标是其他项目，例如从分支到上游项目，则默认批准规则将从目标（上游）项目而不是源（叉子）获取.
Editing / overriding approval rules per merge request
在 GitLab 企业版 9.4 中引入.
默认情况下，MR 作者或具有足够权限的用户可以编辑每个合并请求（MR）中列出的合并请求批准规则. 可以在禁用此功能.
一种可能的情况是添加比默认设置中定义更多的批准者.
创建或编辑合并请求时，请找到” 批准规则”部分，然后按照与添加/编辑默认批准规则相同的步骤进行操作.
Multiple approval rules
Introduced in 11.10.
在 GitLab Premium 中，每个合并请求可以有多个批准规则，每个项目可以有多个默认批准规则.
添加或编辑多个默认规则与添加或编辑单个默认批准规则相同 ，不同之处在于，即使已经定义了规则，” 添加批准规则”按钮仍可用于添加更多规则.
同样，每个合并请求中编辑或覆盖多个批准规则与每个合并请求中相同，只是即使已定义一个规则，” 添加批准规则”按钮仍可用于添加更多规则.
当合格的批准人批准合并请求时，它将减少批准人所属的所有规则的剩余批准数.
Scoped to Protected Branch
in GitLab Premium 12.8.
批准规则通常仅与特定分支（例如 . 在配置可以通过导航到项目的“设置” ，展开” 合并请求批准” ，然后从” 目标”分支下拉列表中选择” 任何”分支 ，将这些作用域一下子作用于所有受保护的分支.
或者，您可以从” 目标”分支下拉列表中选择一个非常特定的受保护分支：
要启用此配置，请参阅 .
当合格的批准者访问一个开放合并请求时，可能是以下之一：
如果所需的批准数目尚未满足，他们可以通过点击批准它显示的批准按钮.
如果已经满足所需的批准数量，则他们仍然可以通过单击显示的“额外批准”按钮来批准 .
他们已经批准了此合并请求 ：他们可以删除他们的批准.
注意：如果在项目设置中启用了” 则不允许合并请求作者批准自己的合并请求.
满足批准规则后，如果没有其他阻止请求，则可以合并合并请求. 请注意，合并请求仍可能被其他条件阻止，例如合并冲突， 挂起的讨论或 .
可以通过以下步骤找到合并请求批准的项目设置： 设置>常规和扩展合并请求批准 .
Prevent overriding default approvals
默认情况下，用户可以在合并请求中编辑批准规则. 如果禁用，则所有新合并请求的将由默认批准规则确定. 要禁用此功能：
- 取消选中可以覆盖每个合并请求所需的批准人和批准复选框.
- Click 保存更改.
Resetting approvals on push
当新的提交被推送到合并请求的源分支时，您可以强制删除对合并请求的所有批准. 如果禁用，则即使合并请求中添加了更改，批准也将持续. 要启用此功能：
- Check the 将新提交推送到其源分支时，删除合并请求中的所有批准 checkbox.
- Click 保存更改.
注意：重新定义来自 UI 的合并请求时，批准不会重置. 但是，如果更改了目标分支，则批准将被重置.
Allowing merge request authors to approve their own merge requests
Introduced in 11.3.
您可以允许合并请求作者自行批准合并请求. 作者也必须包含在批准者列表中，以便能够批准其合并请求. 要启用此功能：
- 取消选中” 阻止合并请求作者批准合并请求”复选框，默认情况下启用此复选框.
- Click 保存更改.
Prevent approval of merge requests by their committers
in GitLab Starter 11.10.
您可以阻止已提交合并请求的用户批准它. 要启用此功能：
- 选中阻止提交者批准合并请求复选框.
- Click 保存更改.
Require authentication when approving a merge request
Introduced in 12.0.
注意：要在批准合并请求时要求身份验证，必须在登录限制下启用为 Web 界面启用的密码身份验证 . 在管理区域中.
您可以强制批准者输入密码以进行身份验证，然后再添加批准. 这使电子签名能够获得批准，例如所定义的签名. 要启用此功能：
- 选中需要用户密码批准复选框.
可以将合并请求批准配置为在合并请求引入漏洞时需要安全团队成员的批准.
有关更多信息，请参见合并请求中的安全性批准 .
从 ，默认情况下会提供更新的批准界面. 在 12.0 之前的版本中，除非启用了功能标志，否则更新的界面不可用，这可由实例管理员从 Rails 控制台中完成.
使用以下命令来启动 Rails 控制台：
