改坏一个文件后最怕的不是文件本身，而是“回退”这个动作会不会顺手把提交历史一起改掉。多数版本控制工具里，恢复单个文件的命令只作用于工作区和暂存区，不会新建或删除提交；真正会动历史的是 amend、rebase、以及 reset 之后强推这类操作。所以处理顺序建议是：先用状态命令圈定改动范围，再只对目标文件做恢复，最后用历史命令核对提交条目有没有变化。

如果这次改动还没提交，只恢复工作区里的那一个文件，通常不触碰历史；如果已经提交，就要在“新增一个撤销提交”和“改写原有提交”之间做选择，后者在已共享分支上会波及其他人。判断依据不是感觉，而是三处对照：状态输出里的文件清单、单文件差异是否归零、提交列表与 HEAD 标识在操作前后是否一致。

先确认改坏的范围只在工作区

先做一次状态查询，不要急着回退。命令名以本机实际为准，常见形态是：

# Scion 有自己的子命令体系时，先用 scion help 确认等价写法
scion status

# 如果 Scion 工作区背后是 Git，可以直接用
git status `--short`
git status `--porcelain`

读状态输出时重点看三块：暂存区里有没有这个文件、工作区里有没有未暂存的改动、有没有未跟踪的新文件。区分是否已提交的方法很直接——只要该路径能出现在 git log -- <file> 的结果里，而当前状态里它显示为 modified，那“改坏”的那部分就落在未提交区间；如果状态区是空的、这个文件根本不在清单里，说明你的错误已经进了某个提交，得换后面的路走。

把被动过的文件列全，可以用这几条：

git status `--porcelain`
git diff `--name-only`
git diff `--cached` `--name-only`

三条输出合起来，就是本次工作区里被改动过的全部路径。先确认清单里只有你打算处理的那一个文件，再往下走；如果清单里还有别人的改动或你自己的其他正常修改，恢复命令就必须带文件路径，不能写成作用于全部路径的形式。

把该文件恢复到上一次提交的样子

恢复单文件的骨架，不同工具叫法不同，常见的是 restore / checkout 加一个路径参数：

# 只恢复工作区中的这一个文件
git restore -- path/to/file

# 旧版 Git 写法
git checkout -- path/to/file

两个要点：路径写完整，不要加 `--hard` 之类的全局开关，也不要省略路径。命令只在单文件层面生效，其他文件的未暂存改动会原样保留。如果目标文件本来就在暂存区里，git restore 默认只动工作区，还需要 `--staged` 才能把暂存那部分也退回去——这一步要看你究竟想回到哪个状态，别一把全退，把本来正确的暂存内容也抹掉。

执行前后各打一次差异，比较稳妥：

git diff -- path/to/file        # 执行前：应能看到你改坏的内容
git restore -- path/to/file
git diff -- path/to/file        # 执行后：预期无输出
git diff `--stat`                 # 确认其他文件没被顺带还原

判定标准是“执行后该路径的差异为空，且 `--stat` 里其他文件的条数和执行前一致”。差异没消失，通常说明改动其实在暂存区，或者你恢复的路径和实际被改的路径不是同一个，先回到上一步重新对清单，别急着换更强的命令。

确认历史没有被重写

给这一步加个可核对的锚点：恢复前先记下当前提交的标识和条数。

git log `--oneline` -n 10 > before.txt
# 执行完恢复动作之后
git log `--oneline` -n 10 > after.txt
diff before.txt after.txt

如果 diff 没有输出，说明最近这些提交的标识、顺序、提交信息都没变，恢复动作停在工作区层面。更细的核对可以同时看分支指向和操作日志：

git rev-parse HEAD
git reflog -n 20

HEAD 标识前后一致，reflog 里也没有出现 amend、rebase、reset 这类会改写历史的条目，基本可以确认历史没被动过。真的发现不一致时，处理顺序建议是：先停下所有写操作，用 reflog 找到改写前的位置，确认那个位置是不是自己想要的，再决定是否把分支指回去；不清楚 reflog 内容时，不要继续叠加 reset 或 push `--force`。已共享分支上出现不一致，先通知协作者，再动手。

如果这个改动已经提交了，改走另一条路

已提交的情况下，“恢复文件内容”和“改写历史”是两件事，不要混着做。

• 撤销提交（revert）：新增一个提交，把目标文件的改动反向抵消。原提交仍然留在历史里，提交数量增加。适合已经推送、别人可能已经拉过的分支。
• 改写历史（amend / rebase / reset 配合强推）：把原提交替换掉，历史中的标识会变。只适合本地未共享的分支，或确认所有协作者都能接受重写并重新同步的场景。

判据还是那条分支有没有共享出去。git log origin/<branch>..HEAD 有输出，说明本地领先、改写余地相对大一些；如果本地和远端指向一致，改写基本只能靠强推，影响的是所有已经基于旧提交工作的人。

多人协作时，动手前需要告知的对象至少包括：正在基于该分支开发的人、已经合并过该分支的下游分支负责人、以及发布或打包流程的负责人。告知内容建议只说三件事——要改哪个提交、改完后的历史标识、其他人需要执行的同步动作。

把这次事故的处理过程写成三步记录

记录不用长，按发现、执行、验证三步写就够，下次同类问题直接照着走：

1. 发现方式：怎么察觉到文件改坏的——哪条状态命令、哪个路径出现在输出里、当时依据什么判断它属于未提交区间。
2. 执行命令：原样贴出实际执行的命令，包含完整路径和参数，别用简写或口头描述。
3. 验证结果：恢复后单文件差异是否为空、git log `--oneline` 前后是否一致、reflog 里有没有出现改写类条目。

这三行留下来的价值，在于把“我改坏了什么”和“我做了什么恢复动作”分开写，下一次遇到需要改写历史的场景时，能对照记录看出当时的判断边界：哪些操作只影响工作区，哪些会动提交。条件允许的话，把这条记录放进仓库内的变更日志或团队文档，而不是只留在聊天记录里。