Help us learn about your current experience with the documentation. Take the survey.

自动合并

  • 层级:Free, Premium, Ultimate
  • 提供:GitLab.com, GitLab Self-Managed, GitLab Dedicated

如果合并请求的内容已准备好合并,您可以选择 设置为自动合并。当所有必需的检查都成功完成后,合并请求将自动合并,您无需记住手动合并该合并请求。

合并检查让您专注于审查合并请求的内容,并使用项目设置来确定其可合并性。当您审查合并请求时,如果您同意合并请求的更改,请将其设置为自动合并。GitLab 会强制执行您的项目设置,直到合并请求满足所有合并检查(如必需的代码所有者和批准规则),否则无法合并。满足所有必需的合并检查后,合并请求将自动合并,无需您进行任何操作。

合并检查包括通过的 CI/CD 流水线,以及更多内容:

  • 必须给予所有必需的批准。
  • 没有其他合并请求阻止此合并请求。
  • 不存在合并冲突。
  • 无论 项目设置 如何,CI/CD 流水线必须成功完成。
  • 所有讨论都已解决。
  • 合并请求不是 草稿
  • 所有外部状态检查都已通过。
  • 合并请求必须处于开放状态。
  • 不存在被拒绝的策略。
  • 如果您的项目 要求合并请求引用 Jira 问题,则合并请求的标题或描述中包含 Jira 问题链接。
  • 如果合并请求设置了 合并后 日期,当前时间必须晚于配置的日期。

有关完整检查列表及其 API 等效项,请参阅 合并状态

自动合并已准备就绪

设置自动合并后,您无法更改合并请求合并时哪些问题会 自动关闭

自动合并合并请求

先决条件:

  • 您必须拥有项目的 Developer 角色或更高。
  • 如果您的项目配置要求,合并请求中的所有讨论 必须已解决
  • 合并请求必须已获得所有必需的批准。

从命令行推送时执行此操作,请使用 merge_request.merge_when_pipeline_succeeds 推送选项

从 GitLab 用户界面执行此操作:

  1. 在左侧边栏,选择 搜索或跳转至 并找到您的项目。
  2. 选择 代码 > 合并请求
  3. 选择要编辑的合并请求。
  4. 滚动到合并请求报告部分。
  5. 可选。选择您想要的合并选项,例如 删除源分支压缩提交编辑提交消息
  6. 查看合并请求小部件的内容。如果它包含 问题关闭模式,请确认 该问题在此工作合并时应关闭: 此合并请求关闭问题 #2754。
  7. 选择 自动合并

在选择 自动合并 后但在流水线完成前对合并请求进行评论, 会阻止合并,直到您解决所有现有讨论。

取消自动合并

您可以取消合并请求的自动合并。

先决条件:

  • 您必须是合并请求的作者,或者是拥有至少 Developer 角色的项目成员。
  • 合并请求的流水线必须仍在进行中。

执行此操作:

  1. 在左侧边栏,选择 搜索或跳转至 并找到您的项目。
  2. 选择 代码 > 合并请求
  3. 选择要编辑的合并请求。
  4. 滚动到合并请求报告部分。
  5. 选择 取消自动合并

取消流水线成功时合并的选项

自动合并的流水线成功

如果流水线成功,合并请求将合并。如果流水线失败,作者可以重试任何失败的作业,或推送新的提交来修复问题:

  • 如果重试的作业在第二次尝试时成功,合并请求将合并。
  • 如果您向合并请求添加新的提交,GitLab 会取消该请求, 以确保新的更改在合并前经过审查。
  • 如果您向合并请求的目标分支添加新的提交,并且您的项目 只允许快进式合并请求,GitLab 会取消该请求以防止合并冲突。

要对流水线状态进行更严格的控制,您还可以在合并前 要求成功的流水线

要求合并前流水线成功

您可以配置您的项目,要求在合并前必须有完整且成功的流水线。此配置适用于:

因此,禁用 GitLab CI/CD 流水线 不会禁用此功能,但您可以将其与外部 CI 提供商的流水线一起使用。

先决条件:

  • 确保您项目的 CI/CD 配置为每个合并请求运行一个流水线。
  • 您必须拥有项目的 Maintainer 角色或更高。

启用此设置:

  1. 在左侧边栏,选择 搜索或跳转至 并找到您的项目。
  2. 选择 设置 > 合并请求
  3. 滚动到 合并检查,然后选择 流水线必须成功。 此设置还会在没有流水线时阻止合并请求合并, 这可能与 某些规则冲突
  4. 选择 保存

如果 为同一合并请求运行多种类型的流水线, 合并请求流水线优先于其他类型的流水线。例如, 一个较旧但成功的合并请求流水线允许合并请求合并, 即使有一个较新但失败的分支流水线。

允许跳过的流水线后合并

当您为项目设置 流水线必须成功 时, 跳过的流水线 会阻止 合并请求合并。

先决条件:

  • 您必须拥有项目的 Maintainer 角色或更高。

更改此行为:

  1. 在左侧边栏,选择 搜索或跳转至 并找到您的项目。
  2. 选择 设置 > 合并请求
  3. 合并检查 下:
    • 选择 流水线必须成功
    • 选择 跳过的流水线视为成功
  4. 选择 保存

防止在特定日期前合并

如果您的合并请求不应在特定日期和时间前合并,请设置 合并后 日期。 此值设置合并(或合并列车)可以开始的时间。但是,合并的确切时间可能会有所不同, 具体取决于其他合并检查的满足情况或合并列车的长度。

先决条件:

  • 您必须拥有项目的 Developer 角色或更高。

执行此操作:

  1. 在左侧边栏,选择 搜索或跳转至 并找到您的项目。
  2. 选择 代码 > 合并请求
  3. 选择要编辑的合并请求。
  4. 选择 编辑
  5. 找到 合并后 输入框并选择日期和时间。
  6. 选择 保存更改

故障排除

合并请求无法合并尽管没有失败的流水线

在某些情况下,您可以 要求合并前流水线成功, 但无法合并没有失败流水线的合并请求。该设置要求存在成功的流水线, 而不是没有失败的流水线。完全没有流水线的合并请求不被视为有成功的流水线,因此无法合并。

启用此设置时,使用 rulesworkflow:rules 来确保 为每个合并请求运行流水线。

合并请求仍可合并尽管流水线失败

在某些情况下,您可以 要求合并前流水线成功, 但仍可以合并有失败流水线的合并请求。

合并请求流水线对 流水线必须成功 设置具有最高优先级。 如果为同一合并请求运行多种类型的流水线,GitLab 只检查 合并请求流水线的成功状态。

如果出现以下情况,合并请求可能有多个流水线:

  • 导致 重复流水线rules 配置:一个合并请求流水线和一个分支流水线。 在这种情况下,最新的合并请求流水线的状态决定合并请求是否可以合并,而不是分支流水线。
  • 由针对与合并请求相同分支的外部工具触发的流水线。

在所有情况下,请更新您的 CI/CD 配置,以防止同一合并请求出现多种类型的流水线。