git reset --hard 会强制将 HEAD、暂存区和工作目录全部重置到指定提交，永久丢弃其后所有本地更改；三区同步清空，不可逆，执行前须确认无未推送提交、无重要未暂存修改、且哈希准确。
直接说结论：用 git reset --hard <commit-hash></commit-hash> 可以强制将当前分支的 HEAD、暂存区和工作目录全部重置到指定提交，但会永久丢弃该提交之后的所有本地更改——包括未提交的修改、已暂存但未提交的文件、以及后续的提交记录。
执行前必须确认的三件事
这不是后悔药，一旦执行，没备份就找不回来：
- 当前分支没有未推送的提交（否则远程仓库和其他协作者会和你“失联”）
- 工作目录里没有你还没
git add或git commit的重要临时改动（git status一定要是干净的，或至少心里有数） - 目标
commit-hash是准确的（建议先用git log --oneline -n 20翻看最近提交，复制完整哈希或用HEAD~2这类相对引用）
reset --hard 和其他 reset 模式的根本区别
关键在“三区”（工作目录、暂存区、HEAD）是否同步重置：
-
git reset --soft <commit></commit>：只移动 HEAD，暂存区和工作目录不动 → 后续git commit会把原暂存内容打包成新提交 -
git reset --mixed <commit></commit>（默认）：移动 HEAD + 重置暂存区，工作目录保留 → 文件变成“已修改未暂存”状态 -
git reset --hard <commit></commit>：三区全清空 → 工作目录文件内容直接变成目标提交时的样子，所有差异被抹掉
常见误操作场景与补救提示
最常出问题的是：想回退但忘了自己刚改了一半的 config.js，一执行 --hard 就没了：
- 如果刚执行完但还没关终端，可以用
git reflog查到重置前的 HEAD 位置（比如显示abc1234 HEAD@{0}: reset: moving to abc1234，那HEAD@{1}就是之前的位置），再git reset --hard HEAD@{1}拉回来 - 如果已经关闭终端，且没做任何新操作，
git fsck --lost-found有时能捞出悬空对象，但不保证成功 - 千万别对已推送到远程的提交做
--hard后又git push --force，除非你明确通知了所有协作者并协调好了
真正危险的不是命令本身，而是执行前没看清 git status 和 git log 的输出——尤其当分支上有多个未合并的 feature 分支时，--hard 会直接切断它们和当前分支的连接。动手前花三十秒确认，比事后两小时翻 reflog 强得多。
