Git 作为最流行的版本控制系统，其强大之处不仅在于记录代码变更，更在于提供了丰富的“后悔药”机制。然而，面对 reset、revert、checkout 和 restore 这几个命令，许多开发者常常混淆它们的用途，甚至因为误用而丢失工作成果。本文将系统梳理这四个命令的核心逻辑、适用场景与正确用法，帮助你在任何需要“撤销”的时刻都能从容应对。
一、理解 Git 的三个工作区域
在深入命令之前，必须先明确 Git 的三个核心区域：
- 工作区（Working Directory）：你当前编辑的文件目录。
- 暂存区（Staging Area / Index）：通过
git add将变更放入的区域，准备提交。 - 版本库（Repository）：通过
git commit将暂存区内容永久记录的区域。
撤销操作的本质，就是在这三个区域之间移动或修改数据。不同的命令作用于不同的区域，理解这一点是正确选择命令的关键。
二、git restore：现代且安全的撤销方式
git restore 是 Git 2.23 版本引入的命令，旨在替代 checkout 在文件恢复方面的功能。它的设计更清晰，且默认不会意外切换分支。
1. 撤销工作区的修改
如果你修改了某个文件但尚未 git add，想放弃这些修改：
git restore <file>
例如：git restore index.html 会将 index.html 恢复到最近一次提交（或暂存）的状态。注意：此操作会永久丢弃工作区中未暂存的修改，无法恢复。
2. 撤销暂存区的修改（取消 add）
如果你已经 git add 了文件，但想将其从暂存区撤回，同时保留工作区的修改：
git restore --staged <file>
这相当于旧版的 git reset HEAD <file>。执行后，文件回到“已修改但未暂存”状态，工作区内容不变。
3. 同时撤销工作区和暂存区
git restore --source=HEAD --staged --worktree <file>
或者简写为：
git restore -s HEAD -S -W <file>
这会将该文件彻底恢复到 HEAD 提交的状态，丢弃所有未提交的变更。
三、git checkout：旧时代的万能工具
在 restore 和 switch 出现之前，checkout 承担了切换分支和恢复文件的双重职责。虽然现在仍可用，但容易产生歧义。
1. 恢复文件（类似 restore）
git checkout -- <file>
这等同于 git restore <file>，用于丢弃工作区修改。注意 -- 用于区分文件名和分支名，避免歧义。
2. 切换分支
git checkout <branch>
这是 checkout 最常用的功能。Git 2.23 后推荐使用 git switch <branch> 来专门切换分支，语义更明确。
3. 切换到某个提交（分离头指针）
git checkout <commit-hash>
这会进入“分离头指针”状态，适合临时查看历史版本，但不要在此状态下提交，除非你明确知道自己在做什么。
建议：新项目或新团队应优先使用 restore 和 switch，避免 checkout 的歧义。
四、git reset：移动分支指针的利器
reset 用于将当前分支的 HEAD 指针移动到指定提交，并可选择性地重置暂存区和工作区。它有三种主要模式：
1. --soft：仅移动 HEAD
git reset --soft HEAD~1
撤销最近一次提交，但保留所有变更在暂存区。适合“提交早了”或“想重新组织提交内容”的场景。
2. --mixed（默认）：移动 HEAD 并重置暂存区
git reset HEAD~1
撤销提交，并将变更从暂存区移回工作区。这是最常用的模式，适合“提交了但想重新修改再提交”。
3. --hard：彻底重置
git reset --hard HEAD~1
危险操作：撤销提交，同时丢弃暂存区和工作区的所有变更。数据将无法通过 Git 恢复（除非有备份或 reflog）。仅在确认不需要这些变更时使用。
4. 回滚到特定提交
git reset --hard <commit-hash>
将当前分支直接指向该提交，之后的所有提交都会从分支历史中“消失”。如果这些提交已经推送到远程，不要使用 reset，否则会导致团队协作混乱。
五、git revert：安全的公共历史撤销
与 reset 不同，revert 不会删除任何提交，而是创建一个新的提交来抵消指定提交的变更。这是撤销已推送提交的唯一安全方式。
1. 撤销单个提交
git revert <commit-hash>
Git 会生成一个新提交，其内容与目标提交相反。例如，如果目标提交添加了一行代码，revert 提交就会删除那一行。
2. 撤销多个提交
git revert <oldest-commit>..<newest-commit>
注意范围是左开右闭，且顺序重要。更稳妥的方式是逐个 revert，或使用 --no-commit 手动控制。
3. 处理冲突
如果 revert 的提交与后续提交有冲突，Git 会暂停并提示你解决冲突。解决后执行 git revert --continue 即可。
核心优势：revert 保留了完整的历史记录，适合团队协作和已推送的分支。
六、场景化选择指南
| 场景 | 推荐命令 |
|---|---|
| 丢弃工作区未暂存的修改 | git restore <file> |
| 取消暂存（add 后想撤回） | git restore --staged <file> |
| 修改最近一次提交信息 | git commit --amend |
| 撤销最近一次提交但保留变更 | git reset --soft HEAD~1 |
| 撤销最近一次提交并重新修改 | git reset HEAD~1 |
| 彻底丢弃最近一次提交及变更 | git reset --hard HEAD~1 |
| 撤销已推送的提交 | git revert <commit> |
| 临时查看历史版本 | git checkout <commit> 或 git switch --detach <commit> |
七、安全建议与最佳实践
- 慎用
--hard：在执行git reset --hard前，先用git stash保存当前工作，或确认变更已备份。 - 已推送的提交用
revert：永远不要对公共分支使用reset后强制推送，除非你完全清楚后果。 - 善用
git reflog：即使误操作，reflog记录了 HEAD 的移动历史，可以帮你找回丢失的提交。例如git reset --hard HEAD~3后想恢复，可用git reflog找到之前的哈希再 reset 回去。 - 提交前用
git diff --staged检查：避免提交错误内容，减少撤销需求。 - 小步提交：细粒度的提交让 revert 和 reset 的影响范围更小，更容易管理。
结语
Git 的撤销命令看似复杂，但只要牢记“三个区域”和“是否已推送”这两个判断维度，就能快速选出正确的工具。restore 负责文件级恢复，reset 用于本地历史调整，revert 是公共历史的守护者，而 checkout 虽仍可用，但建议逐步迁移到 restore 和 switch。掌握这些命令的适用边界，你就能在 Git 的世界里游刃有余，不再惧怕任何“手滑”时刻。
未经允许不得转载：任鹏个人博客 » Git 撤销操作全指南：reset、revert、checkout 与 restore 的正确用法
朋友圈点赞图在线生成源码
