合并请求指从一个分支合并到另一个分支,代码服务的一个重要组成部分,是代码协作的基础。合并请求可能是新需求、优化改造、缺陷修复等。典型的合并请求处理过程涉及如何提交合并请求、如何对合并请求进行评审以便确定是否接受请求、由谁来处理合并、合并后的通知机制等问题。
通过 合并请求 功能,您可以:
比较两个分支之间的变化。
在线查看和评论代码修改,并 记录问题状态。
设置评审规则,支持多种评审需求,如多人评审等。
设置合并规则 以控制合并准入。
展示 合并冲突列表。
压至合并,让提交历史记录更清晰。
查看合并请求版本,合并请求版本基于 push 产生,您可以选择并比较这些合并请求差异的版本。
应用场景
合并请求的准入设置可以有多种情况,例如:团队中的开发人员需要提交代码。从创建合并请求到通过评审、合并代码分支的整体流程如下:
创建一个新的分支并修改、提交代码。
创建合并请求,提交代码变更。
团队其他成员进行评审,在合并请求的评审记录中进行反馈、讨论。
开发人员根据评审意见进行修改,解决问题。
通过评审后,分支予以合并。
合并请求设置
在合并请求设置中,您可以设置合并规则,要求代码分支必须通过评审才能合并。操作步骤如下:
从左侧导航栏进入 代码服务 > 我的仓库,选择目标代码仓库,点击进入代码仓库详情页面。
在页面上方,点击 设置 > 合并请求设置。
开启 是否必须评审才能合并 开关。一旦开启,分支必须通过评审才能合并;如果关闭,可以由单个合并请求确定是否需要评审。
点击 更新 使设置生效。
评审设置
在评审设置中,您可以设置评审规则。操作步骤如下:
从左侧导航栏进入 代码服务 > 仓库,选择目标代码仓库,点击进入代码仓库详情页面。
在页面上方,点击 设置 > 评审设置。
在 评审通过票数 中,设置通过评审所需的票数。
开启 评审人可以设置为提交人 开关,允许评审人和提交人为同一个人。该设置项主要针对一次合并请求包含多人修改的场景。
开启 当源分支更新时清空投票 开关。一旦开启,若合并请求还有未完成的评审,当源分支代码变更时,原投票数清 0。
点击 更新 使设置生效。
负责人有权限修改评审设置,如果在创建合并请求后修改设置,则合并请求会保留之前的设置,但可以通过编辑合并请求来修改。
新建合并请求
可通过以下任一入口创建合并请求:
在代码仓库详情页面,点击 合并请求 > 新建合并申请,开始创建合并请求。
在代码仓库详情页面,点击 分支 > 合并请求,开始创建合并请求。
提交评论
进入合并请求详情页面,对合并请求进行评审。
评审模式
支持提交单个问题和开启评审两种模式:
提交单个问题/评论:提交评审后就会发出通知。
开始评审:点击 开始评审 后,会触发评审模式。评审完成后,整体提交评审并发出通知。
评论类型
评论区分为问题和评论。问题是需要本次解决的;评论可能是一个优化建议不需要本次解决。
评论范围
评论的范围有两种:针对 commit diff
的评论 和 整体评论。
查看 commit diff 的评论
在合并请求详情页中,点击 提交记录 标签可查看提交记录列表。
点击 文件变更 标签可查看修改的内容,可选择对应的行数添加评论。创建的评论都会显示评论区域。
整体评论
指在讨论区域针对整个合并请求进行整体评论。
给问题增加标记
在代码仓库详情页面,点击 设置 > 标记,可创建并管理标记。可通过标记对评审问题进行分类,比如标记为代码风格、代码逻辑等。
查找差异文件
在 文件变更 标签页中,可通过搜索框查找差异文件。当有大量文件变更时,可以通过下拉导航轻松地跳转到任何更改的文件。
更改问题状态
可将问题标记为以下状态:已解决、未解决、无效问题。
评审通过
在合并请求详情页,评审人点击 通过 后,系统会根据通过票数确定合并请求是否通过评审。
评审区域展示评审情况:
如果已到达评审票数(即评审通过的票数等于设置的评审通过票数),则分支可以合并。但是,除了评审票数外,如合并冲突、目标分支写权限不满足等也同样无法进行合并操作。
合并
在代码库中使用保护分支控制合并权限。开发人员将功能分支推送到代码库中,创建合并请求通过评审后,拥有保护分支写权限的用户(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)