可集成系统 与CodeArts Req系统集成，使用CodeArts Req的工作项关联对应代码提交，包括代码提交、代码分支和合并请求场景。Repo系统默认设置了关联。 Repo可关联的工作项类别请参考下表。 表2 Repo可关联工作项参数说明 项目类型 可关联工作项 Scrum Epic，Feature，Story，Task，Bug IPD-系统设备类 IR，SR，AR，Bug IPD-独立软件类 IR，US，Bug IPD-自运营软件/云服务类 Epic，FE，US，Task，Bug

集成策略 可选枚举值，用于限定用户在关联工作项时的选择条件。 排除状态：选中状态的工作项不可关联合并请求。例如，当前图片展示是“Scrum”项目可关联的工作项，选择“新建”，表示新建状态的工作项不可关联合并请求。 可关联类别：选中类型的工作项可以被关联。例如，如果选择Epic，表示“Epic”类型的工作项可以关联合并请求，不同类型项目可关联的工作项请参考表2。 应用分支：选中的分支将受，其他分支无限制。例如，如果正则表达式为“Branch_*”，表示所有以“Branch_”开头的分支的合并请求将遵循上述的“排除状态”和“可关联类别”设置，正则表达式规则请参考常见的正则表达式示例。

自动提取单号规则 约束与限制： 前缀、后缀、分隔符不能互相包含，否则提取效果不符合预期。 分隔符为空时，前缀和后缀不能为“;”。 后缀为空时，前缀和分隔符不能为“\n”。 前缀、分隔符、后缀为全字符匹配，不支持正则表达式。 配置步骤： 自动提取单号规则表示可以根据代码提交信息自动提取单号，请参考下表进行配置。 表3 自动提取单号规则参数说明 参数 说明 单号前缀 非必填。支持多个前缀，最多10个，每个最多200字符。 分隔符 非必填。默认为“;”。 单号后缀 非必填。默认为使用换行。

常见的正则表达式示例 常见的正则表达式示例可参考常见的正则表达式示例。 表3 常见正则表达式示例 规则 示例 单个a或b或c字符 [abc] 非a或b或c的字符 [^abc] 在a到z范围内的小写英语字母字符 [a-z] 在a到z范围外的字符 [^a-z] 在a到z或A到Z范围内的大小写英语字母字符 [a-zA-Z] 任意单个字符 . 匹配“a”或“b” a|b 任意空白字符 \s 非空白字符 \S 阿拉伯数字字符 \d 非阿拉伯数字字符 \D 字母、数字或下划线的字符 \w 非字母、数字或下划线的字符 \W 匹配括号中的内容（不捕获） (?:...) 匹配并捕获括号中的内容 (...) 零个或一个a a? 零个或更多a a* 一个及以上a a+ 三个a a{3} 三个a以上 a{3,} 3到6个a a{3,6} 文本开头 ^ 文本末尾 $ 单词边界 \b 非单词边界 \B 换行符 \n 回车符 \r 制表符 \t 空字符 \0

配置项目级的合并请求规则 合并请求规则包含四个部分：合入机制、合入条件、MR设置和合并模式。 表2 合入机制的参数说明 参数 说明 合入机制 必填参数。包含两个选项： 打分机制：包含代码检视，以打分为基础，可设置最低合入分值，分值范围为0~5分。只有分数和必选评审达到门禁条件时，代码才可以合入，勾选打分机制时需设置最低分值。 审核机制：包含代码检视和合并审核两个步骤，以通过人数为基础，只有审核通过的人数达到门禁条件时，代码才可以合入。 说明： 合并请求默认为“审核机制”，可手动切换为“打分机制”。 修改合入机制后，会改变合并请求的工作流，但之前创建的合并请求仍保留之前的合入机制。 表3 合入条件参数说明 参数 说明 合入条件 非必填参数。包括两个选项： 勾选“评审问题全部解决才能合入”，如果评审意见被勾选为“这是一个需要被解决的问题”，则合入条件会提示“存在未解决的评审意见”且“合入”按钮置灰；如果只是一个普通的评审意见，则不存在“已解决”开关，也不会被合入条件拦截。 如果勾选“必须与CodeArts Req关联”，被关联的所有E2E工作项校验必须通过；一个MR只能关联一个单号；可添加多个分支配置合并请求策略，支持手动输入通配符匹配，按回车确认，如：*-stable或production/*。 表4 MR设置参数说明 参数 说明 禁止合入自己创建的合并请求 勾选后，用户在查看自己创建的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只有一个提交信息。 表5 合并模式的参数表 参数 说明 通过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操作。