文档

合并请求

更新时间:

合并请求指从一个分支合并到另一个分支,代码服务的一个重要组成部分,是代码协作的基础。合并请求可能是新需求、优化改造、缺陷修复等。典型的合并请求处理过程涉及如何提交合并请求、如何对合并请求进行评审以便确定是否接受请求、由谁来处理合并、合并后的通知机制等问题。

通过 合并请求 功能,您可以:

  • 比较两个分支之间的变化。

  • 在线查看和评论代码修改,并 记录问题状态

  • 设置评审规则,支持多种评审需求,如多人评审等。

  • 设置合并规则 以控制合并准入。

  • 展示 合并冲突列表

  • 压至合并,让提交历史记录更清晰。

  • 查看合并请求版本,合并请求版本基于 push 产生,您可以选择并比较这些合并请求差异的版本。

应用场景

合并请求的准入设置可以有多种情况,例如:团队中的开发人员需要提交代码。从创建合并请求到通过评审、合并代码分支的整体流程如下:

  1. 创建一个新的分支并修改、提交代码。

  2. 创建合并请求,提交代码变更。

  3. 团队其他成员进行评审,在合并请求的评审记录中进行反馈、讨论。

  4. 开发人员根据评审意见进行修改,解决问题。

  5. 通过评审后,分支予以合并。

合并请求设置

在合并请求设置中,您可以设置合并规则,要求代码分支必须通过评审才能合并。操作步骤如下:

  1. 从左侧导航栏进入 代码服务 > 我的仓库,选择目标代码仓库,点击进入代码仓库详情页面。

  2. 在页面上方,点击 设置 > 合并请求设置

  3. 开启 是否必须评审才能合并 开关。一旦开启,分支必须通过评审才能合并;如果关闭,可以由单个合并请求确定是否需要评审。

  4. 点击 更新 使设置生效。

评审设置

在评审设置中,您可以设置评审规则。操作步骤如下:

  1. 从左侧导航栏进入 代码服务 > 仓库,选择目标代码仓库,点击进入代码仓库详情页面。

  2. 在页面上方,点击 设置 > 评审设置

  3. 评审通过票数 中,设置通过评审所需的票数。

  4. 开启 评审人可以设置为提交人 开关,允许评审人和提交人为同一个人。该设置项主要针对一次合并请求包含多人修改的场景。

  5. 开启 当源分支更新时清空投票 开关。一旦开启,若合并请求还有未完成的评审,当源分支代码变更时,原投票数清 0。

  6. 点击 更新 使设置生效。

说明

负责人有权限修改评审设置,如果在创建合并请求后修改设置,则合并请求会保留之前的设置,但可以通过编辑合并请求来修改。

新建合并请求

可通过以下任一入口创建合并请求:

  • 在代码仓库详情页面,点击 合并请求 > 新建合并申请,开始创建合并请求。

  • 在代码仓库详情页面,点击 分支 > 合并请求,开始创建合并请求。

提交评论

进入合并请求详情页面,对合并请求进行评审。

评审模式

支持提交单个问题和开启评审两种模式:

  • 提交单个问题/评论:提交评审后就会发出通知。

  • 开始评审:点击 开始评审 后,会触发评审模式。评审完成后,整体提交评审并发出通知。

评论类型

评论区分为问题和评论。问题是需要本次解决的;评论可能是一个优化建议不需要本次解决。

评论范围

评论的范围有两种:针对 commit diff 的评论整体评论

查看 commit diff 的评论

在合并请求详情页中,点击 提交记录 标签可查看提交记录列表。

点击 文件变更 标签可查看修改的内容,可选择对应的行数添加评论。创建的评论都会显示评论区域。

整体评论

指在讨论区域针对整个合并请求进行整体评论。

给问题增加标记

在代码仓库详情页面,点击 设置 > 标记,可创建并管理标记。可通过标记对评审问题进行分类,比如标记为代码风格、代码逻辑等。

查找差异文件

文件变更 标签页中,可通过搜索框查找差异文件。当有大量文件变更时,可以通过下拉导航轻松地跳转到任何更改的文件。

更改问题状态

可将问题标记为以下状态:已解决、未解决、无效问题。

评审通过

在合并请求详情页,评审人点击 通过 后,系统会根据通过票数确定合并请求是否通过评审。

评审区域展示评审情况:1

如果已到达评审票数(即评审通过的票数等于设置的评审通过票数),则分支可以合并。但是,除了评审票数外,如合并冲突、目标分支写权限不满足等也同样无法进行合并操作。

合并

在代码库中使用保护分支控制合并权限。开发人员将功能分支推送到代码库中,创建合并请求通过评审后,拥有保护分支写权限的用户(Master 用户)完成合并。

合并冲突

当出现冲突时,合并请求中会展示冲突文件列表,可通过点击 解决冲突 旁的问号图标查看如何在本地解决冲突。

说明

不检测路径变更的重命名冲突。例如,在分支 a,执行 git mv file1 file2; 在分支 b,执行git mv file1 file3,这不会视为冲突,这两个文件合并后都将出现在分支中。

压制合并

选择压制合并(squash merge)可以在合并时将合并请求的所有提交合并为一个,并保留一个清除历史记录。它将合并请求中的所有更改作为单个提交。

假设某用户提交了 3 个合并请求,分别是 “1st”、“2nc”、“3rd”:

  • 如果采用一般的合并方式,会有“1st”、“2nc”、“3rd”及合并产生的“Merge branch…”共 4 个提交;

  • 如果采用压制合并,就会把“1st”、“2nc”、“3rd”这 3 个提交压制成“Sqush merge…”这 1 个提交及合并产生的“Merge branch…”提交。

压制合并的提交信息是除“Sqush merge…”说明外,还会把被压制的 3 个提交信息汇总展示。

启用压制合并

在合并请求详情页中,选择 压制提交

使用场景

在 feature 分支上工作时,有时想要提交当前的进度,但不关心提交消息。那些提交不一定包含重要信息,因此不需要也不应该将其包含在目标分支中。

通过压制合并,可以将合并请求中的提交包含到单个提交中。这样,基本分支的历史记录就会保持干净,并提供有意义的提交消息,并且在必要时更容易回滚。

合并请求版本

每次推送到与合并请求关联的分支时,都会创建新版本的合并请求差异。当您访问包含多个推送的合并请求时,可以选择并比较这些合并请求差异的版本。

合并请求版本基于 push 产生。因此,如果您在一次推送中 push 了 5 次,那么下拉菜单中会计入 5 个选项。默认情况下,会显示最新版本的更改。但是,您可以从版本下拉列表中选择较旧的版本。

您还可以将合并请求版本与旧版本进行比较,以查看中间发生了哪些变化。

  • 本页导读 (0)
文档反馈