更新时间:2023-07-25 GMT+08:00
分享

合并请求

合并请求设置位于仓库详情中的 设置 > 策略设置 > 合并请求

“合并请求”应用于合入合并请求,当配置的合并请求条件全部满足时,才可以合入合并请求。合并请求有两种机制,打分机制和审核机制。

此设置只针对被设置的仓库生效。只有仓库管理员和仓库所有者能看到这个页面且有设置权限。

合入机制

  • 打分机制:包含代码检视,以打分为基础,可设置最低合入分值,分值范围为0~5分。只有分数和必选评审达到门禁条件时,代码才可以合入,勾选打分机制时需设置最低分值。
  • 审核机制:包含代码检视和合并审核两个步骤,以通过人数为基础,只有审核通过的人数达到门禁条件时,代码才可以合入,勾选审核机制时建议设置分支策略

合并请求默认为“审核机制”,可手动切换为“打分机制”

切换合入机制后,会改变合并请求的工作流,但之前创建的合并请求仍保留之前的合入机制。

合入条件

表1 字段说明

字段

说明

评审问题全部解决才能合入

勾选后,如果评审意见被勾选为“这是一个需要被解决的问题”,则合入条件会提示“存在未解决的评审意见”“合入”按钮置灰;如果只是一个普通的评审意见,则不存在“已解决”开关,也不会被合入条件拦截。

必须与CodeArts Req关联

  • 只能关联一个单号:勾选后,一个MR只能关联一个单号。
  • 所有E2E单号校验必须通过:勾选后,被关联的所有E2E单号校验必须通过。
  • 选择分支配置合并请求策略:可添加多个分支配置合并请求策略,支持手动输入通配符匹配,按回车确认,如:*-stable或production/*。

是否将星级评价作为合入门禁

勾选后,星级评价功能入口开启,必须至少有一位Committer及以上权限进行星级评价,否则星级评价不通过,则请求无法合入。

MR设置

表2 字段说明

字段

说明

禁止合入自己创建的合并请求

勾选后,您在查看自己创建的MR时,“合入”按钮置灰,自己无法合入,需要找其他有合入权限的人合入。

允许仓库管理员强制合入

项目创建者和管理员有强制合入的权限,当合入条件不满足,也可通过“强行合并”按钮合入MR。

允许合并请求合并后继续做代码检视和评论

勾选后,已合入MR可继续做代码检视、评论。

是否将自动合并的MR状态标记为关闭状态(如果B MR中的所有commits都包含在A MR中,那么当A MR合并后,则B MR会自动合并。默认B MR会标记为merged状态,可以通过该选项控制将B MR标记为Closed状态)

  • 未勾选时,自动合并的MR被标记为已合并。
  • 勾选后,自动合并的MR的状态将会标记为关闭状态。

不能重新打开一个已经关闭的合并请求

勾选后,当分支合并请求已经关闭后,不能将其重新置回“开启”状态,下图中页面右上方的“重开”按钮将隐藏。

此设置一般用于流程管控,使历史评审不会被篡改。

合并请求合入后,默认删除源分支

合并成功后,源分支将被删除。

  • 已经设置成保护分支的源分支不会被删除。
  • 此设置对历史合入请求,不会生效,不必担心启用此设置会丢失分支。

禁止Squash合并

勾选后,“Squash合并”按钮被禁止,且合并请求中无该功能使用入口。

新建合并请求,默认开启Squash合并

Squash合并是指Git在做两个分支间的合并时,会把被合并分支上的所有变更“压缩(squash)”成一个提交,追加到当前分支的后面作为“合并提交”(merge commit),可以使分支变得简洁。Squash合并和普通Merge合并唯一的区别体现在提交历史上:对于普通Merge而言,在当前分支上的合并提交通常会有两个提交信息;而Squash Merge只有一个提交信息。

合并模式

表3 字段说明

字段

说明

通过 merge commit 合并

勾选后,每次合并操作都会产生一个merge commit点,只要没有检测到冲突就能够执行合并操作。即不管基线点是不是最新的点,无冲突就可以合并。

  • Squash合并不产生Merge节点:勾选后,squash合并不会产生merge节点。
  • 使用MR合入者生成Merge Commit :勾选后,可用于记录Commit信息。
  • 使用MR创建者生成Merge Commit: 勾选后,可用于记录Commit信息。

通过 merge commit 合并(记录半线性历史)

勾选后,每次合并操作会记录一个merge commit提交,但是与“通过merge commit合并”不同,必须基于目标分支最新的commit提交点进行提交,否则会提示开发者进行rebase操作。这种合并模式下可以非常确定一点,如果merge request能够正确构建,合并完成后目标分支也能够正确构建。

Fast-forward 合并

勾选后,每次合并操作不会记录一个merge commit提交,且必须基于目标分支最新的commit提交点进行提交,否则会提示开发者进行rebase操作。

设置分支策略

单击“新建”按钮,可以为指定分支或该仓库下的全部分支设置合入策略。

仅审核机制支持设置分支策略,打分机制暂不支持。

分支策略优先级示例如下:

  • 假设在仓库下有A策略与B策略,它们配置的分支相同,则系统默认使用最新创建的分支策略。
  • 假设在仓库下有A策略与B策略,A策略配置的分支为a分支与b分支,B策略配置的分支为a分支,在发起目标分支为a分支的合并请求时,系统默认使用B策略。

在审核机制下未设置分支策略,则在发起合并请求时使用默认分支策略,该分支策略支持编辑、查看但不可删除,策略配置如下:

  • 分支:*,默认全部分支且不可修改。
  • 最小检视人数:默认为 0。
  • 最小审核人数:默认为 0。
  • 重置审核门禁:默认勾选。
  • 重置检视门禁:默认勾选。
  • 仅能从以下审核/检视人中追加审核人/检视人:默认不勾选。
  • 开启流水线门禁:默认不勾选。
  • 合并人:默认为空。
  • 审核人:默认为空。
  • 检视人:默认为空。
表4 字段说明

字段

说明

分支

可针对所有分支或某一分支进行设置策略。

最小检视人数

设置最少检视通过的人数,当检视通过的人数满足“最小检视人数”时,审核门禁通过。“0” 表示无需检视人检视通过,也可通过该门禁,但如果某检视人检视不通过,则该门禁显示不通过。

最小审核人数

设置最少审核通过的人数,当审核通过的人数满足“最小审核人数”时,审核门禁通过。“0” 表示无需审核人审核通过,也可通过该门禁,但如果某审核人审核不通过,则该门禁显示不通过。

重置审核门禁

当重新推送代码到MR的源分支时,将MR审核门禁重置。

重置检视门禁

当重新推送代码到MR的源分支时,将MR检视门禁重置。

仅能从以下审核人/检视人中追加审核人/检视人

勾选后,可配置“追加审核人”名单与“追加检视人”名单,当您想在“审核人”“检视人”的必选名单外追加成员时,只允许从“追加审核人”名单与“追加检视人”名单中追加成员。

需要通过流水线门禁

勾选后,合并前需要满足流水线门禁都通过的条件,将CI融入代码开发流程。

合并人

可配置必选合并人名单,在新建合并请求时,该名单将自动同步至合并请求中。

审核人

可配置必选审核人名单,在新建合并请求时,该名单将自动同步至合并请求中。

检视人

可配置必选检视人名单,在新建合并请求时,该名单将自动同步至合并请求中。

必选名单举例:

  • 最小审核人数为2人,若必选审核人名单为空,追加审核人名单2人均审核通过,审核门禁通过。
  • 最小审核人数为2人,若必选审核人名单非空,则该名单内至少一人审核通过,审核门禁才可通过。
分享:

    相关文档

    相关产品