配置项目级的代码仓库设置

合入机制

必填参数。包含两个选项：

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

  • 合并请求默认为“审核机制”，可手动切换为“打分机制”。
  • 修改合入机制后，会改变合并请求的工作流，但之前创建的合并请求仍保留之前的合入机制。

合入条件

非必填参数。包括两个选项：

• 勾选“评审问题全部解决才能合入”，如果评审意见被勾选为“这是一个需要被解决的问题”，则合入条件会提示“存在未解决的评审意见”且“合入”按钮置灰；如果只是一个普通的评审意见，则不存在“已解决”开关，也不会被合入条件拦截。
• 如果勾选“必须与CodeArts Req关联”，被关联的所有E2E单号校验必须通过；一个MR只能关联一个单号；可添加多个分支配置合并请求策略，支持手动输入通配符匹配，按回车确认，如：*-stable或production/*。

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

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

禁止审核自己创建的合并请求

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

禁止检视自己创建的合并请求

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

允许仓库管理员强制合入

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

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

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

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

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

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

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

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

新建合并请求，默认开启合并后删除源分支

勾选成功后，新建MR默认开启“合并后删除源分支”。开启且合并成功后，源分支将被删除。

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

禁止Squash合并

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

• 合入MR时禁止Squash合并。

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

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