云服务器内容精选

  • 配置项目级的合并请求规则 合并请求规则包含四个部分:合入机制、合入条件、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操作。