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

合并请求

  • Tier: Free, Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

合并请求为团队提供了一个中心位置,用于审查代码、进行讨论和跟踪代码更改。 为了帮助说明为什么进行更改,可以将合并请求链接到 issue,并在合并请求合并时自动关闭该 issue。

合并请求有助于确保主题专家审查您提出的更改,并满足您组织的安全要求。 当您在开发过程的早期创建合并请求时,您的团队有时间发现错误和代码质量问题。

查看合并请求时,您会看到:

  • 请求的描述。
  • 代码更改和内联代码审查。
  • CI/CD 管道的信息。
  • 可合并性报告。
  • 评论。
  • 提交列表。

创建合并请求

了解各种 创建合并请求 的方法。

使用合并请求模板

创建合并请求时,GitLab 会检查是否存在 描述模板 以向您的合并请求添加数据。 GitLab 按从 1 到 5 的顺序检查这些位置,并将找到的第一个模板应用到您的合并请求:

名称 项目 UI
设置

default.md
实例
default.md
项目
default.md
无模板
标准提交消息 1 2 3 4 5
包含 issue 关闭模式 的提交消息,如 Closes #1234 1 2 3 4 5 *
以 issue ID 为前缀 的分支名称,如 1234-example 1 * 2 * 3 * 4 * 5 *

标记有星号 (*) 的项目还会附加 issue 关闭模式

查看合并请求

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

要在主页上查看所有合并请求,使用 Shift + m 键盘快捷键,或:

  1. 在左侧边栏,选择 合并请求 图标。

或:

  1. 在左侧边栏,选择 搜索或跳转
  2. 从下拉列表中,选择 合并请求

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

  1. 在左侧边栏,选择 搜索或跳转 并找到您的项目。
  2. 选择 代码 > 合并请求

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

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

  1. 在左侧边栏,选择 搜索或跳转 并找到您的组。
  2. 选择 代码 > 合并请求

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

当查看仓库中的文件时,GitLab 会显示一个徽章,显示针对当前分支并修改该文件的开放合并请求数量。这有助于您识别有待更改的文件。

此功能的可用性由功能标志控制。 有关更多信息,请参阅 查看文件的开放合并请求

要查看文件的开放合并请求:

  1. 在左侧边栏,选择 搜索或跳转 并找到您的项目。
  2. 转到您要查看的文件。
  3. 在屏幕右上角,文件名旁边,查找带有 merge-request-open 开放 合并请求数量的绿色徽章。
  4. 选择徽章以查看过去 30 天内创建的开放合并请求列表。
  5. 选择列表中的任何合并请求以转到该合并请求。

筛选合并请求列表

要筛选合并请求列表:

  1. 在左侧边栏,选择 搜索或跳转 并找到您的项目。
  2. 选择 代码 > 合并请求
  3. 在合并请求列表上方,选择 搜索或筛选结果
  4. 从下拉列表中,选择您要筛选的属性。一些示例:
    • 按环境或部署日期
    • ID:输入筛选条件 #30 以仅返回合并请求 30。
    • 用户筛选:输入(或从下拉列表中选择)以下任何筛选条件以显示用户列表:
      • 已批准,用于已由用户批准的合并请求。仅限 Premium 和 Ultimate。
      • 批准者,用于此用户有资格批准的合并请求。 (有关更多信息,请阅读 代码所有者)。仅限 Premium 和 Ultimate。
      • 合并者,用于由用户合并的合并请求。
      • 审查者,用于由用户审查的合并请求。
  5. 选择或输入用于筛选属性的操作符。以下操作符可用:
    • =:是
    • !=:不是
  6. 输入用于筛选属性的文本。 您可以按 任意 筛选某些属性。
  7. 重复此过程以按更多属性筛选,通过逻辑 AND 连接。
  8. 选择 排序方向 sort-lowest 表示降序, 或 sort-highest 表示升序。

按环境或部署日期

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

  • 环境
  • 部署于之前
  • 部署于之后

使用 快速合并方法 的项目不会返回结果,因为此方法不会创建合并提交。

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

部署于之前部署于之后 筛选时:

  • 日期指的是部署到环境(由合并提交触发)成功完成的时间。
  • 您必须手动输入部署日期。
  • 部署日期使用 YYYY-MM-DD 格式。如果要同时指定日期和时间("YYYY-MM-DD HH:MM"),请用双引号 (") 括起来。

向合并请求添加更改

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

  • 在浏览器中使用 . 键盘快捷键Web IDE 中编辑更改。使用此基于浏览器的方法来编辑多个文件,或者如果您不熟悉 Git 命令。您无法从 Web IDE 运行测试。
  • Gitpod 中编辑更改,如果您需要功能齐全的环境来编辑文件并在之后运行测试。Gitpod 支持运行 GitLab 开发工具包 (GDK)。要使用 Gitpod,您必须在 用户帐户中启用 Gitpod
  • 从命令行 推送更改,如果您熟悉 Git 和命令行。

向合并请求分配用户

要将合并请求分配给用户,在合并请求的文本区域中使用 /assign @user 快速操作,或:

  1. 在左侧边栏,选择 搜索或跳转 并找到您的项目。

  2. 选择 代码 > 合并请求 并找到您的合并请求。

  3. 在右侧边栏,展开右侧边栏并找到 被分配者 部分。

  4. 选择 编辑

  5. 搜索您要分配的用户,然后选择该用户。GitLab Free 允许每个合并请求有一个被分配者,但 GitLab Premium 和 GitLab Ultimate 允许多个被分配者:

    合并请求侧边栏的两个被分配者

GitLab 将合并请求添加到用户的 分配给我的合并请求 页面。

合并合并请求

合并请求审查过程 中,审查者会对您的更改提供反馈。当审查者对更改满意时, 他们可以启用 自动合并,即使某些合并检查失败。 在所有合并检查通过后,合并请求将自动合并,无需您进一步操作。

默认合并权限:

  • 默认分支(通常是 main)是受保护的。
  • 只有 Maintainer 及更高级别的角色可以合并到默认分支。
  • 开发者可以合并针对非受保护分支的任何合并请求。

要确定您是否有权限合并特定合并请求,GitLab 会检查:

  • 您在项目中的 角色。例如,Developer、Maintainer 或 Owner。
  • 目标分支的 分支保护

关闭合并请求

如果您决定永久停止处理合并请求,请关闭它而不是 删除它

先决条件:

  • 您必须是合并请求的作者或被分配者,或
  • 您必须在项目中拥有 Developer、Maintainer 或 Owner 角色

要关闭项目中的合并请求:

  1. 在左侧边栏,选择 搜索或跳转 并找到您的项目。
  2. 选择 代码 > 合并请求 并找到您的合并请求。
  3. 滚动到页面底部的评论框。
  4. 在评论框下方,选择 关闭合并请求

GitLab 关闭合并请求,但保留合并请求、其评论和任何关联管道的记录。

合并时删除源分支

您可以删除合并请求的源分支:

  • 创建合并请求时,通过选择 合并请求接受时删除源分支
  • 合并合并请求时,如果您拥有 Maintainer 角色,通过选择 删除源分支

管理员可以在项目的设置中将此选项设为默认值。

删除分支操作由设置自动合并或合并合并请求的用户执行。 如果用户没有正确的角色(例如在分叉项目中),源分支删除将失败。

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

  • Tier: Free, Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

合并请求通常链式连接在一起,一个合并请求依赖于另一个合并请求中添加或更改的代码。 为了支持保持单个合并请求较小,GitLab 可以在目标分支合并到 main 时更新最多四个开放合并请求。例如:

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

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

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

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

此功能仅在合并请求合并时有效。合并后选择 删除源分支 不会重新定位开放的合并请求。此改进被 提议为后续工作

合并请求工作流

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

  1. 您检出一个新分支,并通过合并请求提交您的更改。
  2. 您收集团队的反馈。
  3. 您使用 代码质量报告 优化代码实现。
  4. 您在 GitLab CI/CD 中使用 单元测试报告 验证您的更改。
  5. 您避免使用与项目许可证不兼容的依赖项,使用 许可证批准策略
  6. 您向您的经理请求 批准
  7. 您的经理:
    1. 推送一个包含其最终审查的提交。
    2. 批准合并请求
    3. 将其设置为 自动合并(以前的 管道成功时合并)。
  8. 您的更改通过 手动作业 部署到生产环境,用于 GitLab CI/CD。
  9. 您的实现成功交付给您的客户。

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

  1. 您检出一个新分支并通过合并请求提交一个新页面。
  2. 您收集审查者的反馈。
  3. 您使用 审查应用 预览您的更改。
  4. 您请求 Web 设计师进行实现。
  5. 您向您的经理请求 批准
  6. 批准后,GitLab:
  7. 您的生产团队 挑选 合并提交到生产环境。

筛选合并请求中的活动

要了解合并请求的历史记录,筛选其活动源以仅显示与您相关的项目。

  1. 在左侧边栏,选择 搜索或跳转 并找到您的项目。

  2. 选择 代码 > 合并请求

  3. 选择一个合并请求。

  4. 滚动到 活动

  5. 在页面右侧,选择 活动筛选 以显示筛选选项。 如果您已经选择了筛选选项,此字段会显示您选择的摘要,如 活动 + 5 个更多

  6. 选择您想要查看的活动类型。选项包括:

    • 被分配者 & 审查者
    • 批准
    • 评论(来自机器人)
    • 评论(来自用户)
    • 提交 & 分支
    • 编辑
    • 标签
    • 锁定状态
    • 提及
    • 合并请求状态
    • 跟踪
  7. 可选。选择 排序 ( sort-lowest ) 以反转排序顺序。

您的选择会在所有合并请求中保持不变。您也可以通过点击右侧的排序按钮来更改排序顺序。

解决讨论线程

当您想在合并请求中结束对话时, 解决讨论线程

GitLab 在合并请求的右上角显示开放讨论线程的数量,如下所示:7 个开放讨论线程

将合并请求中的所有开放讨论线程移动到 issue

如果您在合并请求中有多个开放讨论线程,可以创建一个 issue 来单独解决它们:

  1. 在左侧边栏,选择 搜索或跳转 并找到您的项目。
  2. 选择 代码 > 合并请求 并找到您的合并请求。
  3. 在合并请求中,在右上角找到 开放讨论线程 下拉列表,然后选择 讨论线程选项 ( ellipsis_v )。
  4. 选择 全部解决并创建新 issue
  5. 填写新 issue 中的字段,然后选择 创建 issue

GitLab 将所有讨论线程标记为已解决,并从合并请求添加到新创建 issue 的链接。

将合并请求中的一个开放讨论线程移动到 issue

如果您在合并请求中有一个特定的开放讨论线程,可以创建一个 issue 来单独解决它:

  1. 在左侧边栏,选择 搜索或跳转 并找到您的项目。
  2. 选择 代码 > 合并请求 并找到您的合并请求。
  3. 在合并请求中,找到您要移动的讨论线程。
  4. 在讨论线程的最后回复下方,解决讨论线程 旁边, 选择 创建 issue 以解决讨论线程 ( issue-new )。
  5. 填写新 issue 中的字段,然后选择 创建 issue

GitLab 将讨论线程标记为已解决,并从合并请求添加到新创建 issue 的链接。

防止合并除非所有讨论线程都已解决

您可以防止在讨论线程保持开放时合并合并请求。 当您启用此设置时,只要至少有一个讨论线程保持开放,合并请求中的 开放讨论线程 计数器就会显示为橙色。

  1. 在左侧边栏,选择 搜索或跳转 并找到您的项目。
  2. 选择 设置 > 合并请求
  3. 合并检查 部分,选择 所有讨论线程必须已解决 复选框。
  4. 选择 保存更改

当讨论线程过时时自动解决合并请求中的讨论线程

您可以设置合并请求,当新的推送更改了讨论线程描述的行时自动解决讨论线程。

  1. 在左侧边栏,选择 搜索或跳转 并找到您的项目。
  2. 选择 设置 > 合并请求
  3. 合并选项 部分,选择 当讨论线程过时时自动解决合并请求差异讨论线程
  4. 选择 保存更改

如果推送使差异部分过时,讨论线程现在会被解决。 未更改的行上的讨论线程和顶级可解决讨论线程不会被解决。

移动通知和待办事项

  • Tier: Free, Premium, Ultimate
  • Offering: GitLab Self-Managed

在 GitLab Self-Managed 上,默认情况下此功能不可用。要使其可用,管理员可以 启用功能标志 notifications_todos_buttons。 在 GitLab.com 和 GitLab Dedicated 上,此功能不可用。

启用此功能标志会将通知和待办事项按钮移动到页面的右上角。

  • 在合并请求上,这些按钮显示在选项卡的最右侧。
  • 在 issue、事件和史诗上,这些按钮显示在右侧边栏的顶部。

相关主题