先记住这个答案
应先明确一次重构的共同不变量，基于同一版本准备涉及的接口、实现和调用方修改，在隔离工作区应用并验证整体结果，再形成范围清楚的提交。工具支持整包预检查时可以减少部分应用，但必须核对其真实保证。git apply 默认在部分补丁块不能应用时拒绝整份补丁，使用 --reject 则会改变这种行为；这不等于操作系统提供多文件同时可见，也不等于运行中的服务自动原子升级。跨发布版本还需要兼容策略与明确部署顺序。
- 先确定接口和调用方共同满足的最终不变量
- 核对编辑工具的失败语义与版本前提
- 文件应用、提交和部署具有不同的原子边界
先把需要同时成立的改动列完整
例如函数返回值从布尔值变成结果对象，接口定义、实现、调用方分支和相关测试需要一起适配。只让类型文件先通过不代表业务行为已经正确，遗漏动态调用入口也可能直到运行时才暴露。应从依赖关系和可观察行为核对范围。
隔离工作区能够避免把半成品暴露给其他开发者的日常操作，也便于保留用户已有改动。它不自动隔离外部数据库、共享缓存或运行服务，因此验证时仍要确认实际连接的环境，不应把工作树隔离等同于所有副作用隔离。
预检查能发现冲突但不能锁住未来
git apply --check 可以检查补丁在当前文件状态下是否可应用，随后真正应用仍需要面对文件可能变化的事实。两步之间若有其他写入，预检查结果就可能过期；应缩短窗口、约束并发写入，并在应用失败时读取最新内容重新判断。
下面命令在已准备好的隔离工作区执行，第一条不修改文件，第二条才应用。默认整包失败与 --reject 的部分接受行为不同，Agent 不能在遇到冲突时随手加上后者，然后仍声称所有文件保持完整一致。
git apply --check change.patch
git apply change.patch
git diff --checkchange.patch 是已经审查过且路径受控的多文件补丁。预检查不创建锁，git diff --check 主要发现空白等补丁问题，不能替代编译、测试或业务验收；命令也没有自动创建提交。
修改顺序应服务于可恢复与兼容性
同一次本地重构可以先提供新接口、迁移调用方，再删除旧实现，让中间状态更容易检查；如果只能最终状态编译，也应确保验证与提交发生在整组修改完成之后。失败时检查具体已改路径，恢复自己拥有的修改，不要清空整个工作区。
若生产环境会同时运行新旧版本，单个 Git 提交无法解决协议兼容。应先增加兼容能力，再迁移调用者，最后清理旧字段或接口。数据库变更、异步消息和缓存格式也可能要求独立顺序，不能把本地补丁的成功等同于发布风险已经消失。
容易答错的地方
- 一个 commit 就说明所有文件修改过程是原子的
- 提交记录表达一组版本状态，但编辑过程和运行进程看到文件的时机不同；线上升级还受到部署方式与兼容性的影响。
- 补丁失败后用 --reject 继续就仍然完整应用
- 该选项可能应用可接受部分并留下拒绝块，适合有意识的人工处理；不能把它当作保持整组一致性的自动修复按钮。
面试官还会怎么问？
为什么要在隔离工作区做大重构？
可以固定起点、限制未完成修改的影响并清楚审查差异；仍需保留任务之外的改动，也要注意外部资源并不会随工作区自动隔离。
多文件能否并行编辑？
不相交且契约已确定的部分可以，但依赖同一接口或修改同一路径时需要协调。并行完成后仍要统一核对接口关系和最终行为。
应用后测试失败应该回退整个仓库吗？
不应该。先定位失败是否来自本次改动，保存证据并只处理明确拥有的路径；不能为了恢复一组补丁而删除其他人的未提交工作。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。