撤销操作：后悔药的使用指南

在软件开发过程中，每个人都会犯错：可能提交得太早了，或者不小心暂存了错误的文件，又或者把代码改得一团糟想重头再来。

Git 提供了强大的工具来帮助我们“撤销”这些操作。本章将介绍几种常见的“后悔药”。

修正上一次提交

有时候你刚运行完 git commit，瞬间就发现遗漏了几个文件没有 add，或者提交信息里有一个显眼的错别字。

此时，你不需要撤销提交再重新来过，只需要使用 --amend 选项。

如果你只是想修改最近一次的提交信息（而不修改文件内容），可以直接运行：

git commit --amend

这将打开你默认的文本编辑器，里面包含了上一次的提交信息。你可以修改它，保存并退出，Git 会用新的信息替换旧的提交。

如果你提交后发现漏掉了文件（例如 forgotten_file.js），可以按以下步骤补救：

# 1. 暂存漏掉的文件
git add forgotten_file.js

# 2. 修正提交（--no-edit 表示沿用上次的提交信息，不打开编辑器）
git commit --amend --no-edit

最终，你的 Git 历史中只会看到一个完美的提交，中间那个错误的提交会被覆盖掉。

假设你修改了两个文件：README.md 和 config.json。你原本只想提交 README.md，却习惯性地运行了 git add .，把两个文件都放进了暂存区。

如何把 config.json 从暂存区里拿出来，但保留它在工作区的修改呢？

在 Git 2.23 版本之后，官方引入了语义更清晰的 restore 命令：

# 将 config.json 移出暂存区
git restore --staged config.json

此时运行 git status，你会看到 config.json 变回了“未暂存以备提交”的状态。

在旧版本的教程中，你可能会看到使用 reset 命令：

git reset HEAD config.json

这两个命令的效果是一样的，但 restore --staged 更容易记忆和理解。

这是最“危险”的操作之一，请务必小心。

假设你在 controller.js 里写了一堆代码，结果越改越乱，甚至代码都跑不起来了。你决定放弃这一小时的工作，把文件恢复到上一次提交时的样子。

同样使用 restore 命令，但不加 --staged 参数：

# 将 controller.js 恢复到最近一次提交的状态
git restore controller.js

在旧版 Git 中，这个操作通常使用 checkout：

git checkout -- controller.js

场景	新版命令 (Git 2.23+)	旧版命令	结果
改写提交	`git commit --amend`	同左	修正最近一次提交
取消暂存	`git restore --staged <file>`	`git reset HEAD <file>`	文件保留在工作区，但移出暂存区
丢弃修改	`git restore <file>`	`git checkout -- <file>`	危险：永久删除工作区修改，不可恢复