合并请求

合并请求 (MR) 是源代码更改进入到分支中的方式。 当您打开合并请求时,您可以在合并之前对代码更改进行可视化和协作。 合并请求包括:

  • 请求的描述。
  • 代码更改和内联代码审查。
  • 有关 CI/CD 流水线的信息。
  • 讨论主题的评论部分。
  • 提交列表。

首先,阅读合并请求简介

查看合并请求

您可以查看您的项目、群组或您自己的合并请求。

查看项目的合并请求

查看项目的所有合并请求:

  1. 在顶部栏上,选择 主菜单 > 项目 并找到您的项目。
  2. 在左侧边栏上,选择 合并请求

或者,要使用键盘快捷键,请按 g + m

查看群组中所有项目的合并请求

查看群组中所有项目的合并请求:

  1. 在顶部栏上,选择 主菜单 > 群组 并找到您的群组。
  2. 在左侧边栏上,选择 合并请求

如果您的群组包含子组,此视图还会显示来自子组项目的合并请求。

查看指派给您的所有合并请求

查看指派给您的所有合并请求:

  1. 在顶部栏上,将光标放在 搜索 框中。
  2. 从下拉列表中,选择 指派给我的合并请求

或者:

或者:

  1. 在顶部栏的右上角,选择 合并请求
  2. 从下拉列表中,选择 分配给您的

过滤合并请求列表

过滤合并请求列表:

  1. 在合并请求列表上方,选择 搜索或过滤结果…
  2. 在出现的下拉列表中,选择您要过滤的属性。
  3. 选择或键入用于过滤属性的运算符。可以使用以下运算符:
    • =:是
    • !=:不是
  4. 输入文本,过滤属性。您可以使用 NoneAny 过滤某些属性。
  5. 重复此过程可以按多个属性进行过滤。多个属性由 AND 逻辑连接。

按 ID 过滤合并请求

您可以过滤合并请求列表,按 ID 查找合并请求。

例如,输入 #30,仅返回合并请求 30。

按核准人过滤合并请求

移动到专业版于 13.9 版本。

要过滤单个合格核准人(代码所有者)的合并请求,您可以键入(或从下拉列表中选择)核准人,并选择用户。

Filter MRs by an approver

按“已核准”过滤合并请求

  • 引入于 13.0 版本。
  • 移动到专业版于 13.9 版本。

要过滤已由特定个人批准的合并请求,您可以键入(或从下拉列表中选择)已核准,并选择用户。

Filter MRs by approved by

按审核者过滤合并请求

引入于 13.7 版本。

要过滤特定个人的审核合并请求的请求,您可以键入(或从下拉列表中选择)审核者,并选择用户。

按环境或部署日期过滤合并请求

引入于 13.6 版本。

要按部署数据(例如环境或日期)过滤合并请求,您可以键入(或从下拉列表中选择)以下内容:

  • 环境
  • 部署前
  • 部署后
note使用快进式合并方法的项目不会返回结果,因为此方法不会创建合并提交。

按环境过滤时,下拉列表会显示您可以选择的所有环境:

Filter MRs by their environment

当通过 Deployed-beforeDeployed-after 过滤时,日期指的是部署到环境(由合并提交触发)成功的时间。 您必须手动输入部署日期。部署日期使用 YYYY-MM-DD 格式,如果您希望同时指定日期和时间("YYYY-MM-DD HH:MM"),则必须引用:

Filter MRs by a deploy date

向合并请求添加更改

如果您有权向合并请求添加更改,则可以通过多种方式将更改添加到现有合并请求,具体取决于更改的复杂性以及您是否需要访问开发环境:

  • 在浏览器中使用 . 键盘快捷键,在 Web IDE 中编辑更改。使用这种基于浏览器的方法来编辑多个文件,或者如果您对 Git 命令不满意。您不能从 Web IDE 运行测试。
  • 如果您需要一个功能齐全的环境来编辑文件,然后运行测试,在 Gitpod 编辑更改。Gitpod 支持运行 GitLab Development Kit (GDK)。要使用 Gitpod,您必须在您的用户帐户中启用 Gitpod。
  • 如果您熟悉 Git 和命令行,从命令行推送更改

将用户指派给合并请求

要将合并请求指派给其它人,请在合并请求的文本区域中使用 /assign @user 快速操作,或者:

  1. 在顶部栏上,选择 主菜单 > 项目 并找到您的项目。
  2. 在左侧边栏中,选择 合并请求 并找到您的合并请求。
  3. 在右侧边栏上,展开右侧边栏并找到 指派人 部分。
  4. 选择 编辑
  5. 搜索您要指派的用户,然后选择用户。

指派多个用户

移动到专业版于 13.9 版本。

如果多个人负责,极狐GitLab 允许合并请求具有多个指派人:

multiple assignees for merge requests sidebar

要将多个指派人分配给合并请求,请在文本区域中使用 /assign @user 快速操作,或者:

  1. 在顶部栏上,选择 主菜单 > 项目 并找到您的项目。
  2. 在左侧边栏中,选择 合并请求 并找到您的合并请求。
  3. 在右侧边栏上,展开右侧边栏并找到 指派人 部分。
  4. 选择 编辑,然后从下拉列表中选择您要指派的所有用户。

要删除指派人,请从同一下拉列表中清除该用户。

关闭合并请求

如果您决定永久停止处理合并请求,建议您关闭合并请求而不是删除它。合并请求的作者和指派人,项目中具有开发者、维护者或拥有者角色的用户可以关闭项目中的合并请求:

  1. 转到您要关闭的合并请求。
  2. 滚动到页面底部的评论框。
  3. 在评论框之后,选择 关闭合并请求

极狐GitLab 关闭合并请求,但保留合并请求、其注释和任何相关流水线的记录。

删除合并请求

建议您关闭而不是删除合并请求。

caution您无法撤消对合并请求的删除。

要删除合并请求:

  1. 以项目所有者角色的用户身份登录极狐GitLab。只有具有此角色的用户才能删除项目中的合并请求。
  2. 前往您要删除的合并请求,然后选择 编辑
  3. 滚动到页面底部,然后选择 删除合并请求

目标分支合并时更新合并请求

  • 引入于 13.9 版本。
  • 在私有化部署版上禁用于 13.9 版本。
  • 在私有化部署版上启用于 13.10 版本。

合并请求通常关联在一起,一个合并请求取决于在另一个合并请求中添加或更改的代码。为了支持使单个合并请求保持较小,当目标分支合并到 main 时,系统最多可以更新四个开放的合并请求。例如:

  • 合并请求 1:将 feature-alpha 合并到 main
  • 合并请求 2:将 feature-beta 合并到 feature-alpha

如果这些合并请求同时开放,并且合并请求 1 (feature-alpha) 合并到 main,系统会将合并请求 2 的目标从feature-alpha 更新为 main

具有互连内容更新的合并请求通常以下列方式之一处理:

  • 合并请求 1 首先合并到 main 中。 然后将合并请求 2 重定向到 main
  • 合并请求 2 被合并到 feature-alpha 中。更新后的合并请求 1,现在包含 feature-alphafeature-beta 的内容,被合并到 main 中。

此功能仅在合并请求合并时有效。合并后选择删除源分支,不会重新定位开放的合并请求。

移动侧边栏操作

引入于 14.10 版本,功能标志moved_mr_sidebar。默认禁用。

启用此功能标志后,您可以在右上角的 合并请求操作 () 中找到以下操作:

当禁用此功能标志时,这些操作位于右侧栏中。

合并请求工作流

对于在团队中工作的软件开发人员:

  1. 您检出一个新分支,并通过合并请求提交您的更改。
  2. 您从团队收集反馈。
  3. 您使用代码质量报告处理实现优化代码。
  4. 您使用 GitLab CI/CD 中的单元测试报告验证您的更改。
  5. 您避免使用许可证与您项目的许可证合规报告不兼容的依赖项。
  6. 您向您的经理请求核准
  7. 您的经理:
    1. 使用他们的最终审核推送提交。
    2. 核准合并请求
    3. 设置为流水线成功时合并
  8. 使用 GitLab CI 的手动作业将您的更改部署到生产环境中。
  9. 您的实施已成功交付给您的客户。

对于为您公司的网站编写网页的 Web 开发人员:

  1. 您检出一个新分支并通过合并请求提交一个新页面。
  2. 您从审核者那里收集反馈。
  3. 您可以使用 Review Apps 预览您的更改。
  4. 您要求您的网页设计师实现。
  5. 您向您的经理请求核准
  6. 一旦获得核准,您的合并请求将被压缩和合并,并通过 GitLab Pages 部署到 staging。
  7. 您的生产团队拣选合并提交到生产环境中。

故障排除

从 Rails 控制台变基合并请求

除了 /rebase 快速操作之外,有权访问 Rails 控制台的用户可以从 Rails 控制台变基合并请求。将 <username><namespace/project><iid> 替换为适当的值:

caution无论运行是否正确,任何直接更改数据的命令都可能造成破坏。我们强烈建议在测试环境中运行它们,并准备好要恢复的实例备份,以防万一。
u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
MergeRequests::RebaseService.new(project: m.target_project, current_user: u).execute(m)

修复不正确的合并请求状态

如果合并请求在合并更改后保持开放,则有权访问 Rails 控制台的用户可以更正合并请求的状态。将 <username><namespace/project><iid> 替换为适当的值:

caution无论运行是否正确,任何直接更改数据的命令都可能造成破坏。我们强烈建议在测试环境中运行它们,并准备好要恢复的实例备份,以防万一。
u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
MergeRequests::PostMergeService.new(project: p, current_user: u).execute(m)

针对具有未合并更改的合并请求运行此命令,会导致合并请求显示不正确的消息:merged into <branch-name>

从 Rails 控制台关闭合并请求

如果通过 UI 或 API 关闭合并请求不起作用,您可能需要在 Rails 控制台会话操作:

caution无论运行是否正确,任何直接更改数据的命令都可能造成破坏。我们强烈建议在测试环境中运行它们,并准备好要恢复的实例备份,以防万一。
u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
MergeRequests::CloseService.new(project: p, current_user: u).execute(m)

从 Rails 控制台删除合并请求

如果通过 UI 或 API 删除合并请求不起作用,您可能需要在 Rails 控制台会话操作:

caution无论运行是否正确,任何直接更改数据的命令都可能造成破坏。我们强烈建议在测试环境中运行它们,并准备好要恢复的实例备份,以防万一。
u = User.find_by_username('<username>')
p = Project.find_by_full_path('<namespace/project>')
m = p.merge_requests.find_by(iid: <iid>)
Issuable::DestroyService.new(project: m.project, current_user: u).execute(m)