在日常开发中，Git 回退代码是高频操作，但 reset、revert 和 checkout 三种方式常常让人困惑。它们都能让代码回到过去的状态，但原理和后果截然不同。本文从三个典型场景出发，带你理清它们的区别，并给出可落地的操作步骤。
场景一：本地提交写错了，想撤销最近几次提交
假设你在本地连续提交了三次，但发现第二次提交引入了问题，此时你希望将代码回退到第一次提交之后的状态。这个场景下，git reset 是最直接的工具。
git reset 会移动当前分支的 HEAD 指针，并可以选择是否重置暂存区和工作目录。它有三种模式：
- –soft：只移动 HEAD，暂存区和工作目录不变，所有改动保留为已暂存状态。
- –mixed（默认）：移动 HEAD 并重置暂存区，但工作目录不变，改动保留为未暂存状态。
- –hard：移动 HEAD 并重置暂存区和工作目录，所有改动被丢弃，不可恢复。
操作示例：
git reset --hard HEAD~2
这条命令将 HEAD 回退两个提交，并丢弃之后的所有改动。注意，–hard 会永久删除工作目录中的修改，如果这些修改没有被提交或备份，将无法找回。因此，在使用 –hard 之前，务必确认你不再需要这些改动。
如果你只是撤销提交但保留改动，可以使用 git reset --soft HEAD~2 或 git reset --mixed HEAD~2。这样，你可以重新整理代码后再次提交。
场景二：已经推送的提交，需要撤销但保留历史记录
当你已经将提交推送到远程仓库，其他协作者可能已经基于这些提交进行了开发。此时，使用 git reset 会改写历史，导致其他协作者的仓库与远程不一致，引发冲突。更安全的方式是使用 git revert。
git revert 会创建一个新的提交，该提交反向应用目标提交的改动，从而撤销其效果，但保留原始提交的历史记录。这种方式不会改写历史，适合用于公共分支。
操作示例：
git revert
执行后，Git 会打开编辑器让你输入提交信息，默认会生成一条类似 “Revert “…”” 的消息。保存后，一个新的提交就创建了，代码恢复到目标提交之前的状态。
git revert 也可以一次撤销多个提交，但建议逐个执行，以便处理可能的冲突。如果回退过程中出现冲突，需要手动解决后继续。
场景三：想临时切换到某个历史版本，但不想影响当前分支
有时你只是想查看某个历史版本的代码，或者临时基于旧版本做实验，而不想移动当前分支的 HEAD。此时，git checkout 是最合适的选择。
git checkout 可以切换到指定的提交或分支，并更新工作目录中的文件。如果你只是查看，可以切换到“分离 HEAD”状态：
git checkout
这会让你处于“分离 HEAD”状态，此时你的工作目录会显示该提交的内容，但当前分支指针不会移动。你可以在此状态下自由查看或实验，但任何新的提交都不会属于任何一个分支，容易丢失。因此，如果你需要基于此状态进行开发，建议先创建新分支：
git checkout -b new-branch
另外，git checkout 也可以用于恢复单个文件到某个版本：
git checkout -- path/to/file
这会将该文件的内容替换为指定提交中的版本，但不会改变 HEAD 指针。
三种方式的对比与选择
方式是否改写历史适用场景风险
git reset是本地未推送的提交–hard 会丢失改动
git revert否已推送的提交可能产生冲突
git checkout否（除非创建新分支）临时查看或恢复文件分离 HEAD 易迷失
选择时，核心原则是：如果提交已经推送，避免使用 reset 改写历史；如果只是想查看旧版本，用 checkout；如果本地提交有误，reset 更灵活。
常见误区与注意事项
- 误区一：reset 和 revert 可以互换。实际上，reset 会删除提交记录，而 revert 会保留记录但新增一个反向提交。在团队协作中，revert 更安全。
- 误区二：checkout 只能切换分支。它也可以切换到任意提交或恢复文件，但需要小心分离 HEAD 状态。
- 误区三：–hard 是万能的。–hard 会丢失所有未提交的改动，且不可恢复。建议先使用
git stash暂存改动，再执行 reset。 - 注意：在执行任何回退操作前，建议使用
git log查看提交历史，确认目标提交的哈希值。
总结
Git 回退代码的三种方式各有适用场景：reset 适合本地未推送的提交，revert 适合已推送的提交，checkout 适合临时查看或恢复文件。理解它们的原理和风险，能让你在开发中更加从容。
参考资料
延伸阅读