Git 作为目前最流行的版本控制系统，其“撤回”功能是日常开发中使用最为频繁的操作之一，这里的“撤回”实际上包含多个层面的含义，可能是撤销工作区的修改、撤销暂存区的操作，或者是撤销已经提交的历史记录，理解并熟练掌握这些撤回命令，能够帮助开发者高效地管理代码，避免误操作带来的麻烦，本文将详细解析 Git 中各种撤回命令的使用场景、具体操作以及注意事项。
我们需要明确 Git 的三个主要工作区域：工作区（Working Directory）、暂存区（Staging Area，也称 Index）以及版本库（Repository，即 .git 目录）,大部分的撤回操作都围绕着这三个区域之间的文件状态转换展开。
最基本的撤回场景是撤销工作区的修改，当你在工作区对某个文件进行了修改，但尚未添加到暂存区，并且希望将这些修改丢弃，恢复到与版本库中完全一致的状态时，可以使用 git checkout 命令，在旧版本的 Git 中，这个命令的用法是 git checkout -- <file>，它会用暂存区或版本库中的内容覆盖工作区的对应文件，在新版本的 Git（自 2.23 版本起）中，推荐使用 git restore 命令来完成同样的操作，因为它更清晰地表达了“恢复”文件的意图，要恢复 example.txt 文件，你可以执行 git restore example.txt，这个命令会直接丢弃工作区自上次提交以来对该文件的所有修改，请务必谨慎使用，尤其是在没有提交修改的情况下,这些修改将永久丢失。
如果已经将修改的文件添加到了暂存区（通过 git add <file>），但尚未提交，此时想要撤回暂存区的操作，即将文件从暂存区移除，使其状态回到“已修改，但未暂存”的状态，可以使用 git reset 命令。git reset 命令有几个常用的选项，对于撤回暂存区操作，应使用 git reset HEAD <file>，这里的 HEAD 代表当前分支头部，指向最新的提交，执行该命令后，example.txt 文件会从暂存区移除，但工作区的修改依然保留，同样，新版本的 Git 推荐使用 git restore --staged <file> 来实现这一功能，语义上更明确：恢复文件到暂存区之前的状态，如果想要一次性将暂存区的所有文件都撤回，可以使用 git reset HEAD 或 git restore --staged .。
当涉及到已经提交的修改时，情况会变得稍微复杂一些，因为提交会生成一个新的版本快照，这里我们主要讨论两种情况：一种是撤销最近的提交，但希望保留修改内容在工作区或暂存区，以便于后续继续修改或提交；另一种是彻底删除某个提交,使其在历史记录中消失。
对于第一种情况，最常用的命令是 git commit --amend，当你刚刚完成一次提交，但发现提交信息写错了，或者忘记了添加某个重要文件时，可以使用这个命令来修改最后一次提交，它会打开一个文本编辑器，让你修改提交信息，或者你可以再次使用 git add 添加文件后执行 git commit --amend，这些新添加的文件会被包含在修改后的提交中，这个操作并不会创建一个全新的提交，而是在原提交的基础上进行修补，另一种更强大的工具是 git reset 的 --soft 选项。git reset --soft HEAD~1 会将 HEAD 指针向前移动一个提交，也就是撤销最近的一次提交，但这次提交的所有修改内容会全部保留在暂存区，这意味着你可以立即使用 git commit 重新提交这些修改，或者先对修改进行调整再提交,这为提交前的修改提供了极大的灵活性。
如果使用 git reset --hard HEAD~1，则会执行一次“硬重置”，它会撤销最近的一次提交，并且同时丢弃该提交的所有修改内容，将这些文件恢复到修改之前的状态，这个操作非常危险，因为它会永久性地删除工作区的修改，请确保在执行前你已经不需要这些修改，或者已经通过其他方式（如 git stash）备份了它们。
如果提交已经推送到远程仓库，情况就更加棘手了，因为直接使用 git reset --hard 会使得本地仓库和远程仓库的历史记录不一致，导致其他协作者出现问题，对于已经推送的提交，正确的做法是使用 git revert 命令。git revert 会创建一个新的提交，这个提交的内容与被撤销的提交正好相反，从而抵消掉原提交的修改，如果原提交是添加了一行代码，git revert 会创建一个提交来删除这行代码，这种方式不会破坏现有的历史记录，而是通过正向的提交来修正错误，因此是处理已推送提交的安全方法，执行 git revert <commit-hash> 即可，Git 会自动尝试生成反向的修改,如果遇到冲突则需要手动解决。
为了更清晰地对比这些撤回命令,我们可以通过一个表格来总结：
| 命令 | 作用范围 | 主要用途 | 对工作区影响 | 对暂存区影响 | 是否影响历史记录 |
|---|---|---|---|---|---|
git restore <file> |
工作区 | 丢弃工作区自上次提交以来的修改 | 恢复到版本库状态 | 无影响 | 否 |
git restore --staged <file> |
暂存区 | 将文件从暂存区移除，回到工作区 | 无影响 | 恢复到已修改状态 | 否 |
git commit --amend |
最新提交 | 修改最新提交的信息或内容 | 可保留修改（用于新提交） | 可覆盖暂存区 | 是（修改原提交） |
git reset --soft HEAD~1 |
最新提交 | 撤销提交，修改保留在暂存区 | 无影响 | 恢复到已暂存状态 | 是（移动 HEAD） |
git reset --hard HEAD~1 |
最新提交及工作区 | 撤销提交并丢弃所有修改 | 恢复到修改前状态 | 恢复到修改前状态 | 是（移动 HEAD 并丢弃修改） |
git revert <commit> |
任意提交 | 创建新提交以抵消旧提交 | 取决于新提交内容 | 取决于新提交内容 | 是（添加新提交） |
除了上述针对文件和提交的撤回命令，git stash 命令也是一个非常实用的“临时撤回”工具，当你正在进行某项功能开发，过程中有一些临时的、不希望提交的修改，但需要切换到其他分支处理紧急任务时，可以使用 git stash 将当前工作区的所有修改（包括暂存区的修改）临时存储起来，执行 git stash save "描述信息" 后，工作区会变得非常干净，就像从未修改过一样，处理完其他分支的任务后，可以切回当前分支，使用 git stash apply 来恢复这些修改（但 stash 列表中的记录不会删除），或者使用 git stash pop 来恢复并删除该 stash 记录。git stash list 可以查看所有的 stash 记录，git stash drop 可以手动删除某个 stash。
Git 的撤回命令体系强大而灵活，但同时也要求开发者对命令的原理和影响有清晰的认识，错误地使用 --hard 选项或对已推送的提交使用 reset 都可能导致严重的问题，在执行任何可能破坏性操作之前，最好先使用 git status 查看当前状态，或者使用 git diff 查看具体的修改内容，确保自己完全理解将要执行的操作所带来的后果，通过合理运用这些撤回命令，开发者可以更加从容地应对开发过程中的各种意外情况,保障代码库的整洁和稳定。
相关问答FAQs
问题1：git reset --hard 和 git revert 有什么本质区别？在什么情况下应该使用哪一个？
解答：git reset --hard 和 git revert 都可以用来“撤销”提交，但它们的原理和适用场景有本质区别。git reset --hard <commit-hash> 会将 HEAD 指针直接移动到指定的提交，并且丢弃该提交之后的所有修改，这会直接修改分支的历史记录，使其变得不线性，这是一个“破坏性”操作，只在本地仓库中使用，绝对不能用于已经推送到远程仓库的分支，否则会导致与其他协作者的历史冲突，而 git revert <commit-hash> 不会修改历史记录，它会创建一个新的提交，这个提交的内容与指定的提交正好相反，从而抵消掉原提交的修改，这是一个“非破坏性”操作，会保留完整的历史记录，因此是处理已经推送到远程仓库的提交的安全方法，如果你想撤销一个本地的、未推送的提交，并且不关心丢失其修改，可以使用 git reset --hard；如果你想撤销一个已经推送的提交，或者希望保留完整的历史记录，那么必须使用 git revert。
问题2：如果我只想撤销某个特定文件在最近一次提交中的修改，而不想影响其他文件，应该怎么做？
解答：要精确地撤销某个特定文件在最近一次提交中的修改，同时保持其他提交和文件不变，最推荐的方法是使用 git revert 命令，并结合 --no-commit 选项，具体步骤如下：执行 git revert HEAD -- <file-path>，这里的 HEAD 指向最近一次提交，<file-path> 是你想要恢复的文件路径，这个命令会生成一个与该文件在最近一次提交中相反的修改，如果你希望手动审查这些修改或与其他修改合并，可以加上 --no-commit 选项，即 git revert HEAD --no-commit -- <file-path>，这样 Git 会将修改应用到工作区和暂存区，但不会自动创建提交，此时你可以使用 git status 查看状态，git diff 检查修改，确认无误后，再执行 git commit 来完成这次撤销提交，这种方法的好处是，它只针对你指定的文件，不会触及其他文件，并且不会破坏历史记录，适用于任何场景,包括已推送的提交。
