一个改动只做一件事
单一职责同样适用于变更本身：一个 PR 只解决一个问题。混合多个主题的改动很难评审（评审者要同时对多件事建模）、很难回滚（想撤一个却要连带别的）、也很难二分定位（出问题不知道是哪个主题引入的）。判断标准很直接：能否用一句话说清这个 PR 做什么。
基本信息
| 判断标准 | 能否用一句话说清这个 PR 做什么 |
|---|---|
| 拆分信号 | 描述里出现「顺便」「同时」这类连接词 |
| 典型反例 | 全库格式化 + 修缺陷 + 升级依赖混在一个提交 |
| 目标状态 | 每个改动独立可合入、独立可回滚 |
常见混装组合
- 格式化或改名 + 真实逻辑改动：噪声淹没重点，评审者放弃细看。
- 重构 + 新功能：行为变化与结构调整交织，出问题无法归因。
- 依赖升级 + 业务改动：依赖引发的问题被业务改动掩盖。
- 缺陷修复 + 顺手的小优化：回滚时无法只退其中一项。
- 文档补充 + 代码改动：文档改动本可单独快速合入。
混装改动的代价
| 维度 | 单一目的 | 多主题混装 |
|---|---|---|
| 评审 | 只需建立一次心智模型 | 多件事交织，容易看漏 |
| 回滚 | 干净退回一项 | 退回会波及无关改动 |
| 二分定位 | 提交边界即问题边界 | 问题归属无法确定 |
| 沟通 | 描述可以很简单 | 描述写长也说不清取舍 |
自查问句
自查问句
# 1. 这个改动能用一句话说清吗？不能就拆
# 2. 如果只回滚其中一半，代码还能工作吗？不能说明耦合了
# 3. 描述里出现了「顺便」「同时」吗？出现就考虑拆
# 4. 每一部分能否独立通过 CI？不能就调整拆分顺序单一目的的 PR 让回滚成为干净操作，而不是连坐：这一点在线上出问题时尤其值钱。
拆分方式按可独立合并的小步提交：先机械改动，再结构调整，最后行为变化，每一步都保持可构建。