审批与合入的分工
审批与合入是两件事，分工约定清楚能省掉很多摩擦。通行做法是评审人负责给出批准，合入由维护者或作者按仓库规则执行；作者批准自己的代码、或者在没有批准的情况下合入，都需要仓库策略明确允许，并且会在平台上留下记录。小团队常让作者在获批后自行合入，大项目则由维护者统一排队。
基本信息
| 默认约定 | 至少一名他人批准后合入，作者不批准自己的代码 |
|---|---|
| 执行者 | 小团队可由作者自行合入，大项目由维护者排队 |
| 记录 | 平台保留批准与合入的时间线，便于事后审计 |
| 例外 | 紧急修复有加急流程，但需要事后补评审 |
典型使用场景
- 明确谁有权点下合并按钮，减少互相等待与催促
- 紧急修复时走加急流程先合入、事后补评审
- 代他人合入之前先在讨论里确认
- 审计或复盘时用平台时间线还原审批过程
- 新成员入职时说明批准与合入的区别
合入前检查
合入前检查
gh pr checks 128 # 确认检查全部通过
gh pr view 128 --json reviewDecision,mergeStateStatus # 复核审批与可合并状态
gh pr merge 128 --squash # 按仓库约定方式合入
gh pr view 128 --json mergedAt,mergedBy # 合入后核对执行记录角色分工
| 角色 | 职责 | 边界 |
|---|---|---|
| 评审人 | 给出批准或反对意见 | 不替作者决定何时合入 |
| 维护者 | 按规则执行合入与排队 | 不合入未获批准的改动 |
| 作者 | 处理意见并推动流程 | 不批准自己的改动 |
紧急修复可以走加急流程，但应在事后补评审并在协作渠道里知会相关人员，避免绕过流程慢慢变成习惯。
代他人合入之前先留言确认：对方可能还有后续提交，或者想换一种合并方式，直接代合会打断他的节奏。