为什么要把大改动拆开
大型评审请求的问题不在行数多，而在于其中混着几件不同的事。拆分时先梳理改动树，再按「可独立合入且可回滚」的边界切：每个请求只做一件事，单独合并之后系统仍然可用。常见切法是按提交重排拆分、先落接口与开关、把机械改动单独成篇。
基本信息
| 拆分依据 | 每个请求只做一件事，单独合并后系统保持可用 |
|---|---|
| 常用手法 | 交互式变基重排并摘出提交到新分支；格式与重命名等机械改动独立提交 |
| 依赖说明 | 在描述里写明与其他请求的先后关系 |
| 拆分后要求 | 每个请求都要能独立跑通检查 |
典型使用场景
- 一次改动同时包含重构与功能，混在一起无法评审
- 大范围重命名或格式化混进了功能改动
- 需要先落地接口定义，再分步接入实现
- 发布前希望低风险改动先合入、高风险改动单独评审
- 同一批改动需要不同角色的评审人
从原分支摘出提交
从原分支摘出提交
git switch -c refactor/extract-utils origin/main # 为拆出的部分新建分支
git cherry-pick <机械改动提交> # 把纯机械改动摘过来
git push -u origin refactor/extract-utils # 推送这个新分支
git log --oneline origin/main..HEAD # 确认这个分支只做一件事常见切法
| 切法 | 适合情形 | 好处 |
|---|---|---|
| 机械改动单独成篇 | 格式化、重命名 | 差异容易逐行核对 |
| 接口先落地 | 新能力需要分步接入 | 后续改动互不阻塞 |
| 按提交拆分 | 分支里已有清晰的提交 | 保留原有的提交粒度 |
| 用开关控制 | 功能需提前合入主干 | 不影响线上行为 |
拆出的每个请求都要能独立跑通检查；如果某一部分无法独立通过，说明边界还需要调整，通常是依赖关系被切错了。
为了让改动提前合入而临时添加的兼容代码，要标注待清理并在后续请求里删除，否则会长期留在主干上。