合并请求从创建到合入，建议拆成创建、预检、评审、审批、合入、合入后确认六个节点。每个节点写清输入、动作、输出和完成标志，并把职责落到作者、评审人、审批人和合入执行人身上。团队从零建立流程时，先定分支策略与合入条件，再定评审规模与审批门槛，最后用模板和检查表固化，流程才能稳定执行。
要点总览（TL;DR）
- 把合并请求流程拆成创建、预检、评审、审批、合入、合入后确认六个节点，每个节点写清输入、动作、输出和完成标志，职责落到作者、评审人、审批人、合入执行人。
- 创建节点用模板固定标题、描述、关联工作项、变更类型和回退说明；预检覆盖构建、静态检查、单元测试和冲突检测，失败由作者修复后重新触发。
- 评审人按业务、模块负责人、架构三类角色分配，意见分阻塞、建议、疑问三级；审批门槛由最少批准数、必需检查通过和阻塞意见清零组成，紧急例外需限定适用人和时限。
- 合入前逐项核对审批、检查、意见和目标分支，合入方式按合并提交、压缩、变基的适用场景选定默认方式；合入后验证目标分支构建、按需部署验证并更新工作项状态。
- 上线前用检查清单确认分支权限、模板与预检、评审审批规则、角色到人和异常回退路径，先小范围运行一到两周再扩大范围。
标准流程的六个节点与核心答案
设计合并请求流程，核心是把“谁在什么条件下做什么、做到什么程度算完成”写清楚。六个节点按顺序推进，其中预检与评审准备可以并行，审批必须在评审意见处理完毕后进行，合入后确认不能省略。节点划分过粗会让责任悬空，过细则增加填写负担，六个节点是多数团队容易执行和检查的粒度。
| 节点 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 创建 | 已完成开发的分支、关联工作项 | 按模板填写标题、描述、变更范围、自测说明，选择目标分支 | 一条信息完整的合并请求 | 必填字段齐全，关联工作项正确 |
| 预检 | 合并请求、自动化检查配置 | 触发构建、静态检查、单元测试、冲突检测 | 检查结果报告 | 全部必需检查通过，无冲突 |
| 评审 | 通过预检的变更、评审人名单 | 评审人按分工阅读变更、提出问题、作者回应修改 | 评审意见与处理记录 | 无未解决的阻塞级意见 |
| 审批 | 评审结论、审批规则 | 审批人核对批准数、检查状态与例外情况后给出审批结论 | 审批记录 | 达到最少批准数且必需检查通过 |
| 合入 | 审批通过的合并请求 | 合入执行人按约定方式合入目标分支 | 目标分支上的合入记录 | 合入成功，关联工作项状态更新 |
| 合入后确认 | 合入后的目标分支 | 验证目标分支构建、必要的部署验证、通知相关人 | 验证结果与状态更新 | 目标分支构建通过，验证结论记录在案 |
节点顺序有两条硬约束：审批在评审之后，合入在审批之后。可并行的部分是预检与评审人分配，预检运行期间可以同步通知评审人准备。可跳过的条件要提前写明，例如仅修改文档或注释的变更可减免部分检查项，但减免规则应由流程维护人统一维护，作者不能自行跳过。
创建与预检：提交前要准备什么
创建节点决定后续环节的信息质量。分支命名与目标分支需要团队统一约定，例如按“类型/工作项编号-简述”命名功能分支，目标分支固定为集成分支或主干，禁止直接向受保护分支推送。约定写进仓库说明或模板提示中，作者创建时按约定选择，减少口头确认。
合并请求模板应包含以下字段，团队可按规模增减：
- 标题：包含工作项编号与变更目的，便于检索和追溯。
- 描述：说明改了什么、为什么改、影响范围，以及自测方式与结果。
- 关联工作项：填写对应需求、缺陷或任务编号，合入后据此更新状态。
- 变更类型：功能、缺陷修复、重构、配置或文档，用于确定检查项和评审人。
- 风险与回退说明：涉及数据、配置或对外接口时，写明回退方式。
- 截图或验证记录：界面类变更附验证结果，便于评审人判断。
预检项建议覆盖四类：构建是否通过、静态检查是否无新增严重问题、单元测试是否通过、与目标分支是否存在冲突。预检失败时由作者负责修复并重新触发，评审人不需要在检查未通过时投入阅读。若失败原因属于环境或流水线本身，由流程维护人排查，作者在合并请求中记录阻塞原因，避免反复重试消耗时间。
评审与审批：评审人怎么定、审批门槛怎么设
评审人按变更内容分配，而不是固定全员参与。常见分工是三类：业务或需求提出方确认变更是否符合预期；模块负责人确认实现质量与对现有代码的影响；架构角色在涉及公共接口、数据模型或跨模块改动时介入。小团队可以一人兼多个角色，但每个角色对应的检查内容要写清楚。
评审意见按严重级别处理，建议分为阻塞、建议、疑问三级。阻塞级意见必须解决或由提出人明确撤回后才能进入审批；建议级意见由作者决定是否采纳，不采纳时说明理由；疑问级意见在回复中澄清即可。级别由评审人标注，作者不能自行降级，避免重要问题在沟通中被稀释。
| 规则项 | 建议配置 | 适用条件 |
|---|---|---|
| 最少批准数 | 常规变更1至2人，涉及公共模块或高风险变更2人以上 | 按变更类型和影响范围区分 |
| 必需检查 | 构建、静态检查、单元测试全部通过 | 文档类变更可减免，需在规则中列明 |
| 阻塞意见清零 | 审批前必须无未解决阻塞级意见 | 所有变更适用 |
| 例外处理 | 紧急修复可由指定审批人单独批准，事后补评审并记录原因 | 仅限线上故障等紧急场景，需限定适用人和时限 |
评审时限需要明确，例如常规变更在提交后一个工作日内给出首轮意见，超过时限由流程维护人提醒或升级给模块负责人。时限的作用是让等待可见，具体时长由团队按节奏确定，不必照搬固定数值。
评审记录与工作项状态的衔接是流程落地的关键动作。在ONES中，合并请求对应的需求或任务可以作为工作项承载，评审结论、审批结果和合入状态回写到同一工作项，评审人从工作项即可看到变更进展，减少在代码平台与任务工具之间反复核对。团队配置时把“评审中”“待合入”“已合入”设为明确状态，状态流转与节点完成标志一一对应。
合入与合入后确认：执行条件与回退准备
合入前逐项确认：审批已达到最少批准数，必需检查全部通过，阻塞级意见已清零，目标分支为约定分支，关联工作项状态正确。任何一项不满足都不进入合入动作，合入执行人有权退回，不需要重新讨论规则。
合入方式按场景选择：合并提交保留完整历史，适合多人协作、需要追溯每次提交的功能分支；压缩合入把多个提交整理为一条，适合提交较碎、希望主干历史清晰的变更；变基合入保持线性历史，适合提交规范、需要逐条保留语义的场景。团队应选定默认方式并写入规范，特殊方式需说明理由。
| 检查项 | 通过标准 | 责任人 |
|---|---|---|
| 审批状态 | 达到最少批准数，例外已记录 | 审批人 |
| 检查状态 | 必需检查全部通过 | 作者、合入执行人 |
| 评审意见 | 无未解决阻塞级意见 | 评审人、作者 |
| 目标分支 | 与约定一致，无冲突 | 合入执行人 |
| 合入后验证 | 目标分支构建通过，必要部署验证完成 | 合入执行人、值班人 |
合入后确认包括三步：观察目标分支构建结果，按需在测试环境做部署验证，更新关联工作项状态并通知相关人。验证失败时按预先写明的回退方式处理，例如回滚合入提交或关闭相关开关，由合入执行人发起、模块负责人确认，并在工作项中记录原因和后续修复安排。
角色与交付物分工
流程节点落到人，才不会停留在文档里。角色可以兼任，但每个节点的交付物要有明确归属。
| 角色 | 主要节点 | 交付物 |
|---|---|---|
| 作者 | 创建、预检、评审回应 | 完整的合并请求描述、自测记录、预检失败修复、评审意见处理说明 |
| 评审人 | 评审 | 分级评审意见、对阻塞意见的确认或撤回 |
| 审批人 | 审批 | 审批结论、例外批准记录 |
| 合入执行人 | 合入、合入后确认 | 合入记录、验证结果、回退处置记录 |
| 流程维护人 | 全流程 | 模板与规则维护、超时提醒、流程检查与调整记录 |
跨角色交接以合并请求中的记录为准：作者提交时@评审人，评审人给出结论时标注级别，审批人批准时引用检查结果，合入执行人完成后回写工作项状态。口头确认可以作为补充，关键结论要落在合并请求或工作项中，便于后续追溯。
示例：一个小团队的合并请求流程落地
以下为演示情景，用于说明流程如何运行，不代表真实团队数据。假设一个六人开发小组，采用主干加短生命周期功能分支的策略，主干受保护，日常变更通过合并请求进入主干，每周一次发布分支。
作者小李接到一个订单列表分页缺陷，从主干拉出分支“fix/ORD-218-分页越界”，完成修改后在代码平台创建合并请求。标题写“ORD-218 修复订单列表分页越界”，描述中说明问题现象、修改点、自测的分页边界用例，关联工作项ORD-218，变更类型选缺陷修复，风险说明写“仅影响列表查询，无数据结构变更”。
预检自动运行，构建和单元测试通过，静态检查提示一处未使用变量。小李删除该变量后重新触发，检查全部通过。系统按规则分配评审人：模块负责人老张审实现，业务方小王确认分页行为符合预期。老张提出一条阻塞意见，指出边界条件缺少测试；小王确认交互无变化。小李补充测试用例并回复，老张撤回阻塞意见。
审批人由老张兼任，核对批准数和检查状态后批准。合入执行人按团队默认的压缩合入方式完成合入，观察主干构建通过，在测试环境验证分页功能，随后把ORD-218状态更新为已合入并通知测试人员。
这次走查暴露两个问题：静态检查的小问题导致预检多跑一轮，团队随后在提交前增加了本地检查步骤；评审人分配依赖手动@，团队把模块与评审人的对应关系写入规则，由系统自动带出。调整后流程执行更顺畅，规则也随之更新到模板说明中。
完成检查：流程上线前逐项核对
流程文档写完后，用下面的清单逐项确认可执行性。每项都要有明确负责人，未通过的项目在上线前补齐。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 分支与权限配置 | 受保护分支已设置，推送与合入权限按角色分配 | 流程维护人 |
| 模板与预检项 | 合并请求模板字段齐全，预检项已配置并成功运行过一次 | 流程维护人 |
| 评审与审批规则 | 评审人分配规则、最少批准数、例外规则可执行且有记录位置 | 模块负责人 |
| 角色明确到人 | 作者、评审人、审批人、合入执行人均有对应人员或轮值安排 | 团队负责人 |
| 异常与回退路径 | 预检失败、验证失败、紧急合入均有处置步骤和责任人 | 合入执行人 |
| 状态衔接 | 工作项状态与流程节点对应，合入后状态更新有人负责 | 流程维护人 |
清单全部通过后，先用一到两周的小范围运行验证规则是否顺手，再逐步扩大适用范围。运行中发现的规则缺口，由流程维护人统一修订模板和检查项，避免每个人按自己的理解执行。
常见问题
团队规模很小，评审人和审批人由同一人兼任，流程还能执行吗？
可以执行，但要把“评审”和“审批”两个动作分开记录。同一个人兼任时，先以评审人身份给出分级意见并确认阻塞意见清零，再以审批人身份核对批准数和检查状态后给出审批结论。两次动作在合并请求中分别留痕，避免出现“自己评自己批、没有记录”的情况。涉及公共接口或数据模型的变更，建议临时引入一位不参与开发的同事做第二评审，降低单人判断的风险。
紧急线上故障需要马上合入，标准流程中的哪些节点可以压缩？
可以压缩的是评审等待和审批人数，不能跳过的是预检和合入后确认。常见做法是由指定的紧急审批人单独批准，合入执行人确认必需检查通过后合入，合入后立即观察目标分支构建和线上表现。事后在一个工作日内补齐评审，并在工作项中记录紧急原因、批准人和补评审结论。例外规则要提前写明适用场景、适用人和时限，避免“紧急”成为绕过流程的通用理由。
预检经常因为环境或流水线问题失败，作者反复重试很耗时，怎么处理？
先把失败原因分成两类：代码问题由作者修复后重新触发；环境或流水线问题由流程维护人排查，作者在合并请求中记录阻塞原因并通知维护人，不反复重试。为减少这类消耗，可以在提交前增加本地检查步骤，把静态检查和单元测试前移到开发机上；同时让流程维护人定期查看预检失败记录，把高频失败项补进模板提示或检查配置。
评审意见提出后作者长期不回应，或者评审人迟迟不给意见，流程怎么推进？
两个方向都要有时限和升级路径。作者侧，超过约定时间未回应评审意见的合并请求，由流程维护人提醒作者，仍无进展则关闭或退回，避免长期挂起占用评审资源。评审人侧，提交后超过约定时限未给出首轮意见的，由流程维护人提醒，必要时升级给模块负责人改派评审人。时限的具体数值由团队按节奏确定，关键是让等待可见、有人负责推动，而不是停留在口头催促。
流程上线后，怎么判断规则是否合适、需要调整？
先小范围运行一到两周，观察三类信号：预检失败是否集中在少数可预防的问题上，评审意见是否大量停留在建议级而阻塞级很少，合入后是否出现需要回退的变更。这些信号指向模板字段、检查项或审批门槛的调整方向。调整由流程维护人统一修订模板和规则说明，并记录修改原因，避免每个人按自己的理解执行。评审等待时长等流动效率指标属于另一类分析主题，可在流程稳定后单独度量。
