大改动怎么切
拆分大改动有两类基本切法：横向按文件、模块或层分组，纵向按依赖顺序分层推进。切完之后每个 CL 都应能独立合入、备份仓库状态仍然可用——「合入一半才能编译」的大爆炸式拆分，会把主干长时间置于不可用状态。
基本信息
| 横向拆分 | 按文件、模块或层分组，每组一个 CL |
|---|---|
| 纵向拆分 | 按依赖顺序：先底层定义，再实现，再调用方 |
| 基础原则 | 先重构后功能：结构调整先行，行为变化单独提交 |
| 验收条件 | 每个 CL 独立可合入，且合入后仓库可构建、测试可运行 |
纵向拆分示例
纵向拆分示例
CL1: 数据模型与接口定义（无调用方，可独立合入）
CL2: 服务实现 + 单元测试
CL3: 入口接线 + 集成测试
CL4: 清理旧实现与临时开关可用的切法
- 机械改动先行：全库改名、格式化、移动文件单独成一个 CL，之后再看真实改动。
- 按层推进：接口或数据结构先落地，实现与调用方随后跟上。
- 按功能点切开：每个 CL 解决一个可描述的问题，凑不出一句话说明的就再拆。
- 先搭脚手架后填内容：新路径先以开关或分支存在，验证通过再切换默认行为。
- 收尾单独一步：删除旧路径、旧开关与兼容代码，放在最后。
拆分方式对比
| 方式 | 适用场景 | 风险 |
|---|---|---|
| 横向按文件 | 改动集中在少数几个模块 | 模块间接口变化时仍会产生耦合 |
| 纵向按依赖 | 新增能力、替换实现 | 依赖链长，前期 CL 看不到效果 |
| 机械与语义分离 | 大规模改名或格式化 | 机械 CL 需要在描述里说明范围 |
| 开关控制 | 行为需要灰度上线 | 开关忘记清理会变成隐藏分支 |
评审者提出「这个改动太大了」时，先与作者确认切法，并给出可执行建议，而不是只要求拆小。
接口先行但实现未到时，评审者无法验证行为，应附设计说明与后续计划。