git reset --soft head~1 是最安全的撤销方式，仅回退 head 指针，保留暂存区和工作区所有修改，适用于修正提交信息、补漏文件或拆分提交。
撤销最近一次提交但保留工作区修改
用 git reset --soft HEAD~1，这是最常用也最安全的撤销方式。它只回退提交记录（即 HEAD 指针），不碰暂存区和工作区，所有已 git add 的文件仍保留在暂存区，未 add 的修改也原样不动。
常见错误是误用 --hard，导致本地修改全丢；或者在多人协作分支上直接重置后强制推送，引发他人历史错乱。
- 适用场景：刚提交完发现漏了某个文件、提交信息写错、或想把多次小提交合并成一次
- 执行后可立刻用
git commit -m "新消息"重新提交 - 如果已推送到远程，需用
git push --force-with-lease覆盖（仅限自己使用的分支）
撤销提交并清空暂存区但保留工作区文件
用 git reset --mixed HEAD~1（--mixed 是默认行为，可省略）。它会把 HEAD 和暂存区都回退，但工作区的修改还在——也就是你 git add 过的文件会从暂存区撤出，变成“已修改未暂存”状态。
典型问题：有人想改提交内容，却用了 --soft，结果 git commit 直接复用旧暂存，没包含新改的代码；此时应先 git add 新文件，再 git commit。
- 适合场景：提交后发现还有本地修改没
add，想一并纳入下一次提交 - 执行后可用
git status确认哪些文件处于 “Changes not staged for commit” - 注意：若之前有
git add .且工作区有大量改动，--mixed后容易遗漏要重新add的文件
已经推送到远程怎么办
关键判断点：有没有其他人基于你这次提交继续开发？如果有，别硬重置；如果没有，且你有权限，才考虑 git push --force-with-lease。
--force-with-lease 比 --force 安全，它会检查远程 HEAD 是否被别人更新过，避免覆盖他人工作。但 Git 不会自动通知你“别人已拉取”，得靠团队沟通或看 CI/CD 流水线状态。
- 强制推送前务必确认：远程分支当前
HEAD就是你本地重置前的那次提交 - GitHub / GitLab 上，若该提交已被 PR 引用或触发了构建，强制推送会导致 PR 显示 “This branch is out-of-date” 或构建失败
- 更稳妥的做法：用
git revert HEAD生成一个反向提交，不改历史，适合共享分支
误删提交后如何找回
Git 的每次操作都会记入 reflog，哪怕 reset --hard 删除的提交，只要没被 GC 清理，通常 30 天内都能找回。
运行 git reflog 查看操作日志，找到目标提交的 HEAD@{n} 标识，再用 git reset --hard HEAD@{n} 恢复。注意 reflog 是本地记录，不随 push/pull 同步。
- 如果连
reflog都找不到，但记得部分文件名或提交信息，可试git fsck --lost-found找悬空对象 -
git gc默认 14 天清理未引用对象，所以别等太久 - 有些 IDE（如 VS Code）的 Git 视图里能直接点“Reflog”标签页，比命令行更直观
