git reset --hard 用于彻底丢弃后续提交，适用于未push的本地修改；git checkout 用于安全查看或恢复单个文件；git revert 推荐团队协作，通过新增抵消提交实现安全回退。
git reset 和 git checkout 是最直接的恢复手段，但选错命令或模式会导致未提交修改丢失、远程历史被覆盖、甚至协作中断。关键不在“能不能回”，而在“回成什么样”和“要不要让别人也跟着回”。
用 git reset --hard 彻底丢弃后续提交
适用于：本地刚提交几条，还没 push，且确定不要这些提交里的任何改动。
执行后，HEAD、暂存区、工作目录全部退回到目标提交的状态，所有未提交的修改（包括已 add 但没 commit 的）都会消失。
-
git reset --hard HEAD~2：退回到前两个提交的位置 -
git reset --hard abc1234：退回到哈希为abc1234的提交（前7位即可） - 如果已经
push过，必须加git push -f才能同步到远程——但这是高危操作，务必先git pull确认没人在这期间推过新提交
用 git checkout 只看不改，或只恢复单个文件
适用于：想临时看看老版本长啥样，或者只想把某个文件（比如误删的配置）拉回来，其他代码不动。
git checkout 不移动 HEAD，只是把工作目录里指定内容换成历史版本，安全系数比 --hard 高得多。
-
git checkout abc1234 -- src/utils.js：只把src/utils.js恢复成abc1234提交时的样子，其余文件不变 -
git checkout abc1234：切换到该提交的「分离头指针」状态，可以查看、测试，但不能直接提交（需先建新分支） - 注意：
git checkout在 Git 2.23+ 中已被git restore和git switch分流，但对历史文件恢复，checkout仍是兼容性最好、最直白的写法
用 git revert 安全撤销某次提交（推荐团队协作场景）
适用于：代码已 push，多人在同一个分支上工作，你只想“反向应用”某次提交，而不是抹掉它。
git revert 不改变历史链，而是在当前 HEAD 后新增一个“抵消提交”，既保留原始记录，又达到逻辑回退效果。
-
git revert abc1234：生成一个新提交，内容是abc1234的逆操作 -
git revert HEAD~2..HEAD：撤销从倒数第三个到最新提交之间的所有变更（注意范围是左开右闭） - 如果遇到冲突，说明被 revert 的修改与当前代码有重叠，需手动解决后
git revert --continue
最容易被忽略的坑：HEAD 指针位置和分支归属
很多人执行完 git reset --hard 就以为万事大吉，结果发现 git status 显示“On branch main”，但 git log 里看不到刚回退的那几条提交——其实是因为 HEAD 已经脱离分支，变成“detached HEAD”状态。
这种情况不会报错，但下次 commit 会生成一个没有分支指向的游离提交，很容易被 Git 垃圾回收清理掉。
- 执行
git reset后，立刻用git branch确认当前分支名是否还在；若显示(HEAD detached at abc1234)，就说明分支指针没跟上 - 补救方法：运行
git switch -c new-branch-name创建新分支指向当前 HEAD，或git branch -f main abc1234 && git switch main强制重置分支指针 - IDEA 或 VS Code 的图形化 Git 工具常默认隐藏这个细节，容易让人误以为操作已完成
