合并请求
合并请求设置位于仓库详情中的
。“合并请求”应用于合入合并请求,当配置的合并请求条件全部满足时,才可以合入合并请求。合并请求有两种机制,打分机制和审核机制。
此设置只针对被设置的仓库生效。
仓库内的仓库成员可以查看该页面,仓库成员是否具有仓库设置权限,请参考权限管理页面。
合入机制
- 打分机制:包含代码检视,以打分为基础,可设置最低合入分值,分值范围为0~5分。只有分数和必选评审达到门禁条件时,代码才可以合入,勾选打分机制时需设置最低分值。
- 审核机制:包含代码检视和合并审核两个步骤,以通过人数为基础,只有审核通过的人数达到门禁条件时,代码才可以合入,勾选审核机制时建议设置分支策略。
合并请求默认为“审核机制”,可手动切换为“打分机制”。
切换合入机制后,会改变合并请求的工作流,但之前创建的合并请求仍保留之前的合入机制。
合入条件
字段 |
说明 |
---|---|
评审问题全部解决才能合入 |
勾选后,如果评审意见被勾选为“这是一个需要被解决的问题”,则合入条件会提示“存在未解决的评审意见”且“合入”按钮置灰;如果只是一个普通的评审意见,则不存在“已解决”开关,也不会被合入条件拦截。 |
必须与CodeArts Req关联 |
|
MR设置
字段 |
说明 |
---|---|
禁止合入自己创建的合并请求 |
勾选后,您在查看自己创建的MR时,“合入”按钮置灰,自己无法合入,需要找其他有合入权限的人合入。 |
禁止审核自己创建的合并请求 |
勾选后,您在查看自己创建的MR时,“审核”按钮置灰,自己无法审核,需要找其他有审核权限的人审核。 |
禁止检视自己创建的合并请求 |
勾选后,您在查看自己创建的MR时,“检视”按钮置灰,自己无法检视,需要找其他有检视权限的人检视。 |
允许仓库管理员强制合入 |
管理员有强制合入的权限,当合入条件不满足,也可通过“强行合并”按钮合入MR。 |
允许合并请求合并后继续做代码检视和评论 |
勾选后,已合入MR可继续做代码检视、评论。 |
是否将自动合并的MR状态标记为关闭状态(如果B MR中的所有commits都包含在A MR中,那么当A MR合并后,则B MR会自动合并。默认B MR会标记为merged状态,可以通过该选项控制将B MR标记为Closed状态) |
|
不能重新打开一个已经关闭的合并请求 |
勾选后,当分支合并请求已经关闭后,不能将其重新置回“开启”状态,下图中页面右上方的“重开”按钮将隐藏。
此设置一般用于流程管控,使历史评审不会被篡改。 |
合并请求合入后,默认删除源分支 |
合并成功后,源分支将被删除。
|
禁止Squash合并 |
勾选后,“Squash合并”按钮被禁止,且合并请求中无该功能使用入口。 |
新建合并请求,默认开启Squash合并 |
Squash合并是指Git在做两个分支间的合并时,会把被合并分支上的所有变更“压缩(squash)”成一个提交,追加到当前分支的后面作为“合并提交”(merge commit),可以使分支变得简洁。Squash合并和普通Merge合并唯一的区别体现在提交历史上:对于普通Merge而言,在当前分支上的合并提交通常会有两个提交信息;而Squash Merge只有一个提交信息。 |
合并模式
字段 |
说明 |
---|---|
通过 merge commit 合并 |
勾选后,每次合并操作都会产生一个merge 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。
- 重置审核门禁:默认勾选。
- 重置检视门禁:默认勾选。
- 仅能从以下审核/检视人中追加审核人/检视人:默认不勾选。
- 开启流水线门禁:默认不勾选。
- 合并人:默认为空。
- 审核人:默认为空。
- 检视人:默认为空。
字段 |
说明 |
---|---|
分支 |
可针对所有分支或某一分支进行设置策略。 |
最小检视人数 |
设置最少检视通过的人数,当检视通过的人数满足“最小检视人数”时,审核门禁通过。“0” 表示无需检视人检视通过,也可通过该门禁,但如果某检视人检视不通过,则该门禁显示不通过。 |
最小审核人数 |
设置最少审核通过的人数,当审核通过的人数满足“最小审核人数”时,审核门禁通过。“0” 表示无需审核人审核通过,也可通过该门禁,但如果某审核人审核不通过,则该门禁显示不通过。 |
重置审核门禁 |
当重新推送代码到MR的源分支时,将MR审核门禁重置。 |
重置检视门禁 |
当重新推送代码到MR的源分支时,将MR检视门禁重置。 |
仅能从以下审核人/检视人中追加审核人/检视人 |
勾选后,可配置“追加审核人”名单与“追加检视人”名单,当您想在“审核人”与“检视人”的必选名单外追加成员时,只允许从“追加审核人”名单与“追加检视人”名单中追加成员。 |
需要通过流水线门禁 |
勾选后,合并前需要满足流水线门禁都通过的条件,将CI融入代码开发流程。 |
合并人 |
可配置必选合并人名单,在新建合并请求时,该名单将自动同步至合并请求中。 |
审核人 |
可配置必选审核人名单,在新建合并请求时,该名单将自动同步至合并请求中。 |
检视人 |
可配置必选检视人名单,在新建合并请求时,该名单将自动同步至合并请求中。 |
必选名单举例:
- 最小审核人数为2人,如果必选审核人名单为空,追加审核人名单2人均审核通过,审核门禁通过。
- 最小审核人数为2人,如果必选审核人名单非空,则该名单内至少一人审核通过,审核门禁才可通过。