从零建立合并请求流程，难点通常不在“要不要评审”，而在节点顺序、风险分级和责任归属没有定清楚：所有变更走同一套重流程会拖慢交付，节点太少又容易把问题留到合入之后。下面按“创建前自检—创建时定范围—评审分级—审批放行—合入门禁—合入后回看”六段给出可执行的设置方法，并说明每个节点的输入、动作、输出与完成标志。
要点总览（TL;DR）
- 从零建立合并请求流程，建议固定六段节点：创建前自检、创建时定范围、评审、审批、合入、合入后回看；节点本身不删减，按变更风险调整评审人数、审批层级和门禁深度。
- 创建节点把质量控制前移：提交前完成本地构建与测试、收敛变更范围，描述中必填变更目的、影响范围、验证方式、回滚方案和风险自评。
- 评审与审批职责分开：评审人确认技术正确性，阻断意见清零且达到最少评审人数才算评审完成；审批人按常规、跨模块、发布前、紧急修复四级风险承担放行责任并留痕。
- 合入以门禁为准：自动检查通过、分支同步、审批齐全才可合入；合入后回看变更是否生效、是否触发回滚，并记录结论。
- 流程上线前核对规则文档、描述模板、评审人名单、自动检查与紧急通道；运行中重点检查跳过节点、审批留痕和例外记录，按迭代或按月复盘调整。
关键节点总览：六段流程与各段完成标志
合并请求的关键节点建议固定为六段，每段回答一个明确问题：变更是否准备好进入评审、评审范围是什么、技术正确性由谁确认、谁承担放行责任、合入条件是否满足、合入后是否按预期生效。节点固定，但节点内的评审人数、审批层级和检查项按变更风险增减，这是避免一刀切的关键。
下表给出六段节点的完整框架，可直接作为流程文档的第一页。
| 节点 | 输入 | 动作 | 输出 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 创建前自检 | 本地代码、关联工作项 | 本地构建与测试、收敛变更范围、填写描述 | 自检记录、合并请求描述 | 自检项全部勾选，描述字段完整 | 提交者 |
| 创建时定范围 | 变更内容、分支 | 标注变更类型与影响范围、关联工作项、指定评审人 | 带标签与评审人的合并请求 | 范围标注清楚，评审人已分配 | 提交者 |
| 评审 | 合并请求、评审规则 | 按分级规则评审、意见分类、轮次收敛 | 评审意见与结论 | 阻断意见清零且达到最少评审人数 | 评审人 |
| 审批 | 评审结论、风险等级 | 按风险层级审批、留痕 | 审批记录 | 对应层级审批通过并留痕 | 审批人 |
| 合入 | 审批通过记录、自动检查结果 | 门禁校验、处理冲突、执行合入 | 合入记录 | 门禁全绿且记录可追溯 | 合入者 |
| 合入后回看 | 合入记录、监控与反馈 | 确认变更生效、判断是否回滚 | 回看记录 | 生效确认完成，异常有处理结论 | 提交者与合入者 |
风险分级决定节点内的配置：低风险变更（文档、注释、小范围配置）保留自检、单人评审和自动检查即可；中等风险变更增加领域评审人；高风险变更（核心逻辑、公共组件、发布前变更）增加多人审批和更严格的合入门禁。六个节点本身不建议删减，删减的是节点内的人数与检查深度。
创建节点：提交前自检与合并请求描述规范
质量控制前移到创建环节，能显著减少评审阶段的返工。创建节点的目标是让评审人拿到一个“范围清楚、验证过、可判断”的变更，而不是替提交者做基础检查。
提交前自检清单建议包含以下条目，全部勾选后才创建合并请求：
- 本地构建通过，相关单元测试或集成测试已运行，结果记录在描述中；
- 变更范围已收敛，不混入无关的格式化、重命名或临时调试代码；
- 新增或修改的逻辑有对应测试，或说明未覆盖的原因；
- 依赖变更、配置变更、数据库变更已单独标注；
- 分支基于最新目标分支，命名符合约定（如 feature/工作项编号-简述、fix/工作项编号-简述）。
合并请求描述采用固定字段模板，避免评审人反复追问背景：
| 字段 | 填写要求 | 是否必填 |
|---|---|---|
| 变更目的 | 解决什么问题，关联工作项编号 | 必填 |
| 影响范围 | 涉及模块、接口、配置、数据，是否影响其他团队 | 必填 |
| 验证方式 | 运行了哪些测试、手工验证步骤与结果 | 必填 |
| 回滚方案 | 回滚步骤、是否需要数据修复、回滚影响 | 必填 |
| 风险自评 | 低、中、高，并说明判断依据 | 必填 |
| 截图或日志 | 界面变更或关键日志 | 按需 |
完成标志是描述字段无空缺、自检项全部勾选、工作项已关联。提交者完成这一步后，合并请求才进入评审分配。若团队使用 ONES 承载研发管理，可将合并请求与工作项关联，让变更目的、影响范围和验证记录随工作项一起留存，评审人从工作项即可看到上下文。
评审节点：评审人分配、分级与轮次控制
评审节点解决“谁来评、评到什么程度、意见何时算收敛”。评审人分配建议遵循三条规则：按代码归属指定模块负责人，按领域指定跨模块评审人，设置最少评审人数。最少人数按风险分级，低风险一人，中等风险一至两人，高风险两人以上且包含领域负责人。
变更类型分级决定评审深度：
| 变更类型 | 评审要求 | 最少评审人数 |
|---|---|---|
| 文档、注释 | 内容准确性检查 | 1 人 |
| 配置、脚本 | 配置项核对与回滚可行性 | 1 人 |
| 核心业务逻辑 | 逻辑正确性、边界条件、测试覆盖 | 2 人，含模块负责人 |
| 公共组件、基础库 | 接口兼容性、调用方影响、版本策略 | 2 人以上，含领域负责人 |
评审意见按三类处理：阻断意见指必须修改才能合入的问题，如逻辑错误、安全风险、缺少必要测试；建议意见指可以改进但不阻塞合入的问题，由提交者决定是否本轮处理；疑问意见指评审人需要澄清的信息，提交者应回复说明。关闭条件是阻断意见全部清零、达到最少评审人数、疑问意见已回复。建议意见可转为后续工作项，避免评审轮次无限延长。
轮次控制建议设定上限：同一合并请求超过两轮仍有新增阻断意见时，由评审人与提交者当面或线上同步确认问题边界，避免文字往返空转。评审结论需要明确写出“通过”“修改后再评”或“关闭”，不留模糊状态。
审批节点：按风险设置审批层级与放行责任
评审与审批承担不同职责。评审人判断技术正确性，对代码质量负责；审批人判断这次变更在当前时点是否可以放行，对业务风险和发布节奏负责。两者可以由同一人兼任，但在流程上应分开记录，避免“评审通过即默认放行”。
审批层级按风险设置，可参考下表：
| 风险等级 | 典型变更 | 审批人 | 留痕要求 |
|---|---|---|---|
| 常规变更 | 单模块内的功能修改、缺陷修复 | 模块负责人 | 审批记录与评审结论关联 |
| 跨模块变更 | 涉及多个模块或接口约定调整 | 相关模块负责人共同审批 | 各审批人意见分别记录 |
| 发布前变更 | 临近发布窗口的变更、配置与数据变更 | 技术负责人加发布负责人 | 审批时间、审批人、放行结论完整 |
| 紧急修复 | 线上故障修复 | 值班负责人先行审批 | 事后补审记录与复盘结论 |
紧急通道需要明确两点：先行审批人有权在故障场景下放行，但必须在约定时间内补齐常规审批并记录原因；事后补审不是形式，需要回看变更内容与常规流程要求的差距，作为流程改进输入。完成标志是对应层级审批通过、审批人与时间可追溯、紧急情况有补审记录。
在工具承载上，ONES 工作项可以记录变更的审批状态与审批意见，使合并请求的放行结论与需求、任务保持同一条记录链，便于发布前集中核对哪些变更已审批、哪些仍在等待。
合入节点：门禁校验与合入后回看
合入节点把“可以合入”变成可校验的条件，而不是依赖合入者的记忆。合入前门禁建议包含四项：自动检查（构建、测试、静态检查）全部通过；分支已同步目标分支且冲突已解决；审批记录齐全且对应当前风险等级；合并请求描述与自检项完整。
合入方式按团队习惯选择合并提交或压缩合并，但需统一要求：提交信息包含工作项编号与变更摘要，避免历史记录无法追溯；合入后删除已合并的临时分支，保持分支列表清晰。合入者只执行门禁校验和合入动作，不代替评审人或审批人做技术判断；门禁不满足时退回对应节点，而不是绕过。
合入后回看关注三件事：变更是否按预期生效，可通过监控、日志或验证步骤确认；是否出现异常需要触发回滚，回滚条件应在描述的回滚方案中提前写明；回看结论是否记录，供后续复盘使用。完成标志是门禁全绿、合入记录可追溯、回看结论已填写。
角色分工与交付物：谁在哪个节点做什么
节点要落地，需要把动作落到角色和交付物上。下表给出责任矩阵，团队可按规模合并角色，但职责边界应保持清晰。
| 角色 | 主要节点 | 交付物 |
|---|---|---|
| 提交者 | 创建前自检、创建、合入后回看 | 自检记录、完整描述、回看结论 |
| 评审人 | 评审 | 分类后的评审意见与评审结论 |
| 审批人 | 审批 | 审批意见与放行结论 |
| 合入者 | 合入 | 门禁校验记录、合入记录 |
| 流程维护者 | 全流程 | 规则文档、模板、例外记录、复盘结论 |
流程维护者负责规则维护与例外记录：当出现紧急通道、门禁豁免或评审人数不足的情况，由流程维护者登记原因、审批人和补做安排，并在固定节奏的复盘中检查例外是否集中出现在某类变更上。例外记录是调整分级规则的依据，而不是追责材料。
示例：一个中等风险变更走完六个节点
以下为演示情景，用于说明节点如何串联，不代表真实团队案例。某团队需要修改订单状态流转逻辑，涉及订单模块与通知模块，自评为中等风险。
- 创建前自检：提交者在本地运行订单模块测试与通知模块联调测试，收敛变更范围，只保留状态流转与通知触发相关改动；描述中填写变更目的（关联工作项）、影响范围（订单模块、通知模块）、验证方式、回滚方案（关闭开关并回退版本）。
- 创建时定范围：分支命名为 feature/订单状态流转，标注变更类型为核心业务逻辑，指定订单模块负责人与通知模块评审人。
- 评审：两位评审人分别检查状态机边界与通知触发条件。评审人提出一条阻断意见（缺少异常状态回退测试）和一条建议意见（日志字段补充请求编号）。提交者补充测试后第二轮评审通过，建议意见转为后续工作项。
- 审批：因涉及两个模块，按跨模块变更由两位模块负责人共同审批，审批意见记录在合并请求中。
- 合入：自动检查通过，分支已同步，审批齐全，合入者执行合入并记录合入时间与版本号。
- 合入后回看：提交者通过监控确认状态流转正常，通知触发符合预期，回看结论记录为“生效正常”。若上线后发现异常状态未正确回退，按回滚方案关闭开关并回退版本，同时登记为例外与复盘输入。
若该变更在发布窗口前被判定为发布前变更，则审批层级提升为技术负责人加发布负责人；若属于线上故障修复，则走紧急通道，由值班负责人先行审批，事后补齐跨模块审批并记录补审结论。
完成检查：流程上线前与运行中的核对项
流程设计完成后，用两份清单判断是否可以上线和是否在正常运行。
上线前检查：
- 规则文档已写明六段节点、风险分级标准、评审人数与审批层级；
- 合并请求描述模板已配置必填字段，自检清单可勾选；
- 分支命名与提交信息规范已发布；
- 评审人分配规则已落到模块与领域负责人名单；
- 自动检查已接入，门禁条件与合入权限已配置；
- 紧急通道的审批人、补审时限与记录方式已明确。
运行中检查：
- 是否存在跳过评审或审批直接合入的记录；
- 审批记录是否包含审批人、时间与结论；
- 例外与紧急通道是否逐条登记并有补审结论；
- 评审轮次是否集中在少数变更上，阻断意见类型是否重复出现；
- 合入后回看记录是否完整，回滚是否按预案执行。
流程调整的触发条件建议设为：同类阻断意见连续出现、例外记录集中、评审轮次明显偏高或门禁频繁被绕过。复盘节奏可按迭代或按月进行，每次复盘只调整一两条规则，并同步更新模板与检查项，避免规则文档与实际执行脱节。
常见问题
团队规模较小、角色经常兼任时，六段节点还需要全部保留吗？
建议保留六个节点的动作，但可以合并承担角色。例如模块负责人同时担任评审人和审批人时，评审结论与审批结论仍要分开记录，避免“评审通过即默认放行”。合入者也可以由提交者以外的人兼任，但门禁校验动作不能省略。节点保留、角色合并，能让流程在小团队里保持可执行，也为后续团队扩张留出调整空间。
紧急修复走快速通道后，事后补审具体要补什么？
补审至少覆盖三项内容：补齐常规流程要求的审批人意见，记录先行审批人、放行时间和放行原因，回看变更内容与常规流程要求的差距。补审结论应登记在合并请求或关联工作项中，并作为复盘输入。若同类紧急修复反复出现，说明常规流程在某类变更上过重或响应不及时，应调整分级规则，而不是长期依赖快速通道。
评审意见长期收敛不了、轮次反复增加，节点设置上应该怎么调整？
先区分意见类型：阻断意见必须修改，建议意见可转为后续工作项，疑问意见由提交者回复澄清。若同一合并请求超过两轮仍有新增阻断意见，由评审人与提交者同步确认问题边界，把争议点收敛到具体范围。节点设置上可以补充两条规则：评审人分配时明确主评审人负责汇总意见，避免多人重复提出同类问题；描述模板中要求写清验证方式，减少因信息不足产生的往返。
合入门禁频繁被绕过，通常要先检查哪里？
先看门禁条件是否与实际交付节奏冲突，例如自动检查耗时过长导致合入者倾向绕过；再看合入权限是否过宽，使不具备校验条件的人也能执行合入。运行中检查应记录每次绕过的原因、审批人和补做安排，由流程维护者定期汇总。若绕过集中在发布前变更，可考虑为这类变更单独设置更快的检查通道，同时保留审批留痕，而不是直接放宽门禁。
流程运行一段时间后，什么信号说明该调整节点或分级规则了？
可关注四类信号：同类阻断意见连续出现，说明创建节点自检或描述模板需要补充检查项；例外记录集中出现在某类变更上，说明分级标准与该类变更的实际风险不匹配；评审轮次明显偏高，说明评审人分配或意见分类规则需要细化；门禁频繁被绕过，说明门禁条件或合入权限需要复核。复盘时每次只调整一两条规则，并同步更新模板与检查项，避免规则文档与实际执行脱节。
