git reset --hard 会彻底清空工作区和暂存区，仅保留目标 commit 快照，未提交修改全部丢失且不可逆；此时 git status 显示“clean”仅表示与 HEAD 一致，并非修改仍存在。
git reset --hard 后文件没了，但 git status 说“working tree clean”
这是最典型的误判：你以为改动能保留，其实 git reset --hard 把工作区也清空了。它只保留目标 commit 对应的快照，其余所有未提交的修改（包括已 add 但没 commit 的、甚至刚保存还没 add 的）全部丢弃，且不提示、不可逆。
关键判断点：git status 显示 “nothing to commit, working tree clean”，不代表你的修改还在——它只说明当前工作区和 HEAD 完全一致，而这个“一致”可能就是空的。
- 执行
git reflog，找 reset 前的 HEAD@{n} 记录（比如HEAD@{1}），那是你刚丢掉的提交位置 - 用
git reset --hard HEAD@{1}回退到 reflog 里的上一状态（注意：仅限本地，reflog 不同步到远程） - 如果 reflog 已被清理（比如执行过
git gc），且没 stash 过，基本无法恢复——这就是为什么改代码前先git stash或git commit -m "wip"是硬习惯
git reset --mixed HEAD~1 后文件变成 “Changes not staged for commit”
这其实是正常行为，不是报错。git reset --mixed（默认模式）会把 HEAD 和暂存区回退到上一个 commit，但把改动留在工作区——所以文件状态从 “Changes to be committed” 变成 “Changes not staged for commit”，意味着你可以重新选择哪些文件要 add，哪些先放着。
容易踩的坑是：看到 “not staged” 就慌着 git checkout -- .，结果把所有未暂存修改也清掉了。
- 想只取消暂存某个文件？用
git restore --staged（Git 2.23+）或git reset HEAD（旧版） - 想保留所有改动但重新组织提交？直接
git add+git commit即可 - 如果误用了
git checkout -- .，立刻停手，再跑一遍git reflog看是否还能找回工作区快照
git reset 后 push 失败，提示 “non-fast-forward”
本地 reset 改写了历史，远程分支比你新，Git 拒绝覆盖——这不是命令失败，是保护机制生效。
能否强制推送，取决于分支性质：
- 个人开发分支（如
feature/login-v2）：用git push -f origin或更安全的git push --force-with-lease origin（它会检查远程是否被别人更新过） - 主干/共享分支（如
main、develop）：绝对不要-f。改用git revert生成反向提交，再git push - 如果已经
push -f了，且别人已基于旧提交开发，必须立刻通知协作者执行git fetch && git reset --hard origin/，否则后续 merge 会出乱子
git reset --soft 后 git commit --amend 提交信息还是旧的
git reset --soft 只移动 HEAD 和保留暂存区，它不会自动打开编辑器；git commit --amend 才负责修改上次提交的内容或信息。
常见操作断层：执行了 git reset --soft HEAD~1，以为下一步 commit 就是 amend，结果直接 git commit 新建了一个提交，导致重复记录。
- 正确链路是：
git reset --soft HEAD~1→git commit --amend（此时会唤起编辑器改 message） - 如果已经多提交了一次，别硬 reset，用
git rebase -i HEAD~2把最后两提交 squash 成一个更干净 -
--amend只能修改最近一次提交；想改更早的，必须用交互式 rebase，且涉及已推送提交时需同步通知团队
真正危险的从来不是命令本身，而是不知道 reset 在哪一层动了什么——工作区、暂存区、版本库，三者状态必须靠 git status 和 git log --oneline -n 5 实时交叉验证，而不是凭记忆或直觉敲回车。
