Best Practices
小批量评审专题
用更小的提交批次和更短的生命周期换取更快的 review 节奏。
- 希望把 Git 用得更稳的个人或团队
- 准备建立协作规范的维护者
- 至少有一次真实协作经验
- 知道常见命令但还没形成稳定习惯
- 把建议当硬规则而忽略上下文
- 只记流程，不理解背后的协作边界
为什么 review 变慢，很多时候不是因为 reviewer 慢
< 200 行变更单一功能/修复自测通过文档已更新
评审时间 < 30 分钟问题遗漏率低反馈更具体合并速度更快
研究表明，评审超过 400 行代码后，缺陷检出率显著下降。保持 PR 小而聚焦。
研究表明，代码评审的效率和质量 当一个 PR 同时包含几十个文件、多个逻辑块、好几轮试错历史时，reviewer 很难快速建立上下文，于是：
- 评论变少
- 漏看风险增加
- 修改往返次数变多
- 合并周期被拉长
小批量评审的目标，就是把 review 从“大型阅读任务”改成“可持续处理的小块工作”。
1. 控制单次评审的范围
更稳的原则是：一次评审只承载一个主要问题。
如果你发现一个分支里同时在做：
- 功能开发
- 重构
- 样式调整
- 文档修正
那通常就已经超出“小批量”的边界了。
2. 分支生命周期越短，评审越轻
长寿命分支往往会自然积累噪声：
- 主线漂移越来越大
- 提交越来越碎
- reviewer 越来越难判断哪些改动是本轮新增
所以小批量评审通常会配合短周期分支一起使用。
如果一项工作需要很久，通常也值得拆成多次可独立评审的里程碑。
3. 拆分不是为了形式，而是为了让讨论更集中
把一次大改拆成多个小 PR 的价值在于：
- 每个 PR 只回答一个主要问题
- 评论更容易集中在关键决策上
- 回滚和补丁合并更容易定位
拆分后，reviewer 更可能给出真正有质量的反馈，而不是只扫一遍“看起来没问题”。
4. 可以用哪些信号判断“这次太大了”
下面这些迹象通常说明你该拆分了：
- 自己已经很难一句话解释这次评审范围
- diff 横跨多个不相关目录
- reviewer 需要先理解大量背景才能评论
- 你已经开始说“这里其实还有一些顺手改的东西”
一旦出现这些信号，继续硬送审通常只会增加往返成本。
5. 一个适合团队落地的小批量原则
可以先从这 4 条开始：
- 一次评审只承载一个核心主题
- 分支生命周期尽量短
- 大任务拆成多个可独立合并的部分
- 送审前先看 diff 范围是否还可讲清楚
这样做的结果通常不是“工作变慢”，而是评审节奏更顺，问题暴露得更早。