git reset --hard适用于本地未推送的实验性改动彻底回退，如feature分支上连续三次测试提交尚未push时直接回到干净状态；但若已推送到远程则禁用，否则会破坏协作历史。
git reset --hard 适合什么场景
只在本地分支操作、且确认不需要保留后续提交和工作区修改时用。比如刚在 feature 分支上连续 commit 了三次测试代码，还没 push，现在想直接回到上上周的干净状态。
常见错误现象：git reset --hard HEAD~3 执行后 git log 看不到那三行提交，但同事说“你昨天推的配置我拉不下来了”——说明你忘了它其实已 push 过。
- 必须确认远程没有该提交，否则强制推送会破坏他人本地历史
-
HEAD~3和HEAD^3效果不同：前者是“往前数3个父提交”，后者是“取第3个父提交”（合并提交才有多个父） - 执行后所有未提交改动永久丢失，
git reflog是唯一找回路径
git revert 是团队协作的默认选择
只要提交已经出现在远程仓库（尤其是 main、develop 这类共享分支），就该无条件优先用 git revert。它不改写历史，只是加一条“反向操作”的新提交。
使用场景举例：CI 构建失败后发现是某次 PR 合并引入的空指针，而其他同事已基于该提交做了新开发。
-
git revert HEAD撤销最新一次提交；git revert abc1234撤销指定哈希提交 - 合并提交需加
-m 1参数，否则 Git 不知道该以哪边为基准撤销 - 如果撤销过程中出现冲突，解决后
git add . && git revert --continue，不是git commit
git commit --amend 只修正最后一次提交
这不是“撤销”，而是“覆盖重写”。适用于刚提交完就发现漏文件、错信息、或想把暂存区新改动合并进去的情况。
容易踩的坑：执行 git commit --amend 后又 push，Git 默认拒绝，报错 rejected non-fast-forward——因为远程有你没拉的新提交。
- 仅限未 push 的提交；若已 push，先
git pull再 amend，否则会多出一个合并提交 -
--amend -m "新消息"可跳过编辑器，适合 CI 脚本中自动修正 - 它不会改变原提交哈希，所以本质上仍是“替换”而非“追加”
reflog 是 reset 后的最后保险
当你手抖敲了 git reset --hard 又关了终端，git log 里提交没了，别急着重写代码——git reflog 记录了 HEAD 每一次移动，包括被 hard reset 抹掉的提交。
典型输出：abc1234 HEAD@{0}: reset: moving to HEAD~1 → def5678 HEAD@{1}: commit: fix login timeout。要找回，就 git reset --hard def5678。
- reflog 默认只保留 90 天（
gc.reflogExpire配置），长期未操作的仓库可能已清理 - 它只存在于本地仓库，无法从远程恢复；别人也看不到你的 reflog
- 对已 push 的提交，reflog 找回后仍需
git push --force-with-lease同步，不能直接push -f
实际协作中最容易被忽略的一点：撤销动作本身不是终点，而是同步信号。哪怕用了最安全的 git revert，也要在 PR 描述或群消息里写明“已 revert abc1234，因触发 XX 异常”，否则下一个人可能又 merge 回去。
