刚执行 git reset --hard 丢掉的提交可从 reflog 恢复，因 Git 对象库仍保留未被 gc 清理的提交；已推送则禁用 reset，须用 git revert 生成抵消提交。
git reset --hard 回退后，代码没了怎么办
直接说结论：没推送过、刚执行 git reset --hard HEAD~1 丢掉的提交，大概率能找回来——Git 自己记着呢，就藏在 reflog 里。
为什么能找回？因为 --hard 只是移动了 HEAD 和清空工作区，但那些被“删掉”的提交对象还在 Git 对象库里，只要没被 git gc 清理，reflog 就保有它们的哈希。
-
git reflog查看操作历史，找到你 reset 前那行（比如显示abc1234 HEAD@{1}: commit: feat: add login） - 用
git reset --hard abc1234或git reset --hard HEAD@{1}恢复 - 如果 reflog 被清空或太久远，且没备份分支，那就真丢了——所以
git reset --hard前建个备份分支（git branch backup-before-hard）不是仪式感，是刚需
想撤销提交但保留修改，别用 --hard
很多人一说“撤销提交”，下意识输 git reset --hard HEAD~1，结果连刚写的代码都清空了。其实绝大多数时候，你真正想要的是“把这次提交撤掉，但代码留着让我再改改”。
-
git reset --soft HEAD~1：只回退HEAD，暂存区和工作区全不动，git status会显示所有变更仍处于“已暂存”状态，适合改提交信息或合并多次提交 -
git reset HEAD~1（即默认--mixed）：回退HEAD+ 清空暂存区，但工作区文件不变，git status显示“Changes not staged for commit”，适合重选文件再提交 -
--hard是唯一会删工作区修改的选项，除非你明确要丢弃全部本地更改，否则别碰它
已经 push 到远程，还能 reset 吗
不能。或者说：技术上可以，但后果严重——你强制推送（git push -f）之后，别人 git pull 会出错，或者拉下来一个“消失的提交”，协作就乱了。
- 已推送的提交，必须用
git revert：它不改历史，而是生成一个新提交，内容刚好抵消目标提交的变更 - 例如撤销最近一次推送：
git revert HEAD，然后git push即可，所有人拉取后历史依然线性、安全 - 如果误用了
reset --hard并push -f，立刻通知协作者，让他们用git fetch && git reset --hard origin/main强制同步（但前提是他们没在那之后做新提交）
只取消暂存，不是撤销提交
经常有人 git add . 后发现加多了，想把某个文件从暂存区拿掉，但又不想丢掉编辑——这不是撤销提交，是“反暂存”。
-
git reset HEAD <file></file>：把指定文件从暂存区移出，工作区内容原样保留 -
git reset不带参数时默认作用于当前分支的HEAD，所以git reset README.md等价于git reset HEAD README.md - 注意别和
git checkout -- <file></file>搞混：后者是丢弃工作区修改，不可逆；前者只是取消暂存，安全得多
最常被忽略的一点：Git 的“撤销”从来不是单向操作，而是靠理解 HEAD、索引（暂存区）、工作目录三层状态的关系。命令本身很简单，但一旦搞错哪一层被重置，补救成本就高了。
