设置项目级合并请求规则-九游平台

合并请求规则概述

合并请求配置是指代码合入条件、合入模式的配置，且项目级的合入请求规则可继承到代码仓库、代码组。

约束限制

当用户角色为“项目经理”或者“项目管理员”，可以设置项目级webhook。

配置合并请求规则

用户可以勾选“开启继承项目设置”，自动继承并使用项目下设置且不支持更改。

用户也可以进入要配置的项目九游平台首页，选择“设置” > “策略设置” > “合并请求”。请按照下列步骤新建合并请求规则：

1. 选择“合入机制”。合并请求有两种机制，打分机制和审核机制，两种模式区别如下：
   • 打分机制，该模式仅包含代码检视，以打分为基础，只有分数达到门禁条件时，代码才可以合入。
   • 审核机制，该模式包含代码检视和合并审核两个步骤，以通过人数为基础，只有检视和审核通过的人数达到门禁条件时，代码才可以合入。
2. 选择合入机制后，参考下表填写其余参数，且该配置对整个代码仓库生效。

   表1 设置合入条件、mr设置、合并模式的参数表

   参数名称	参数解释
   合入条件	此参数非必填，共2个选项： 评审问题全部解决才能合入。勾选后，如果评审意见被勾选为“这是一个需要被解决的问题”，则合入条件会提示“存在未解决的评审意见”且“合入”按钮置灰；如果只是一个普通的评审意见，则不存在“已解决”开关，也不会被合入条件拦截。 必须与codearts req关联。包含如下3个子选项： 只能关联一个单号。勾选后，一个mr只能关联一个单号。 所有e2e单号校验必须通过。勾选后，被关联的所有e2e单号校验必须通过。 选择分支配置合并请求策略。可添加多个分支配置合并请求策略，支持手动输入通配符匹配，按回车确认，如：*-stable或production/*。
   mr设置	该参数非必填。包含如下选项： 禁止合入自己创建的合并请求。勾选后，用户在查看自己创建的mr时，“合入”按钮置灰，自己无法合入，需要找其他有合入权限的人合入。 禁止审核自己创建的合并请求。 禁止检视自己创建的合并请求。 允许仓库管理员及项目经理强制合入。 允许合并请求合并或关闭后继续做代码检视和评论。 是否将自动合并的mr状态标记为关闭状态。如果a mr中的包含在a mr中所有commits，那么当a合并后，则b mr会自动合并。默认b mr会标记为合并状态，可以通过该选项控制将b mr标记为关闭状态。 不能重新打开一个已经关闭的合并请求。默认打开，用户可以根据自己的需要打开或关闭。 新建合并请求，默认开启合并后删除源分支。 禁止squash合并（合入mr时禁止squash合并）。 新建合并请求，默认开启squash合并。
   合并模式	此参数必填，共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操作。

3. 参数填写完成后，单击“提交”，完成合并请求规则的配置。