git reset --soft 是最干净可控的回退方式：仅移动 HEAD 指针，保留所有改动在暂存区，可直接修改后重新提交；--mixed 会将改动退回工作区，--hard 则彻底丢弃未提交变更。
直接说结论：用 git reset --soft 回退，改完再 git commit 重提，这是最干净、可控的方式。别一上来就 --hard，也别盲目 revert——那会多出无意义的提交。
回退但保留改动：用 git reset --soft
这个命令只移动分支指针（HEAD），不碰暂存区和工作区。你上一次 git commit 的所有改动，原封不动留在暂存区里，随时能改完再提交。
- 回退上一个提交：
git reset --soft HEAD~1 - 回退到指定 commit：
git reset --soft a1b2c3d - 执行后立刻
git status，能看到所有文件仍处于 “Changes to be committed” 状态 - 这时你可以：
git add补充新文件、git restore --staged <file>撤出不想提交的、甚至直接编辑文件再git add -u
为什么不用 --mixed 或 --hard？
--mixed（默认）会把改动从暂存区“弹出”到工作区，变成未暂存状态；--hard 更是直接丢弃所有未提交变更——这两者都增加了二次确认和重新 add 的步骤，纯属多此一举。
- 如果你已经
git add过，又想改提交信息或增删文件，--soft是唯一合理选择 -
--hard只适合一种场景：你确定要彻底放弃当前所有未提交修改，且不怕丢数据 - 误用了
--mixed？补救很简单：git add .再git reset --soft HEAD~1，回到起点
已推送到远程怎么办？
如果那个提交已经 git push 上去了，git reset --soft 后再 git commit，本地历史就和远程不一致了。此时必须 git push -f 强推。
- 强推前务必确认：没人基于你刚撤回的那个提交继续开发，否则会破坏他人本地历史
- 团队协作中，受保护分支（如
main）通常禁用force push，这时应改用git revert生成反向提交，而不是重写历史 - 个人功能分支（
feat/login）上，强推是常规操作，不用犹豫
容易被忽略的关键点
回退重提不是原子操作——中间可能漏掉 package.json 或配置文件的变动，尤其当你在回退前后切换过 Node 版本或依赖锁文件时。
- 回退后务必检查：
git diff HEAD@{1} -- package.json package-lock.json（用git reflog找上一状态） - 如果
package-lock.json被改过，仅npm install不够，得rm -rf node_modules && npm ci彻底对齐 -
git reset --soft不影响 stash，但如果你之前git stash过，回退后记得git stash pop手动合并，Git 不会自动帮你
