git revert 是安全回滚方式，它新增反向提交而非删除原提交，保留历史、适合已推送的协作场景；撤销单个提交用 git revert abc123f，连续提交用 git revert head~3..head，冲突时需 git add + git revert --continue。
直接回滚分支到指定版本，git reset --hard 最快但最危险；真正安全的做法取决于你是否已推送到远程、是否多人协作、以及是否想保留历史痕迹。
用 git revert 撤销提交（适合已推送、多人协作）
它不改历史，而是新增一个“反向提交”，所有改动可追溯，远程仓库无需强制推送，CI/CD 也不会中断。
- 撤销单个提交：
git revert abc123f - 撤销连续多个提交（含中间合并）：
git revert HEAD~3..HEAD（注意是两个点，不是三个） - 如果 revert 过程中出现冲突，必须手动解决并
git add+git revert --continue，不能跳过 - revert 后的提交会带自动消息如
Revert "feat: add login button"，建议保留，避免二次混淆
用 git reset --soft 或 --mixed 回退本地分支（未推送前首选）
硬重置（--hard）容易丢代码；软重置只动 HEAD，混合重置清暂存区但留工作区——这两者能给你留出检查和二次编辑的机会。
-
git reset --soft HEAD~2：最后两次提交消失，但修改仍保留在暂存区，可重新git commit整合成新提交 -
git reset --mixed HEAD~1（等价于git reset HEAD~1）：上一次提交被撤回，修改回到工作区，状态为Changes not staged for commit - 切勿在已
git push的分支上用--hard后直接push，除非你明确知道远程分支没人依赖它 - 执行 reset 前，先
git status和git log --oneline -n 5确认目标 commit 是否正确
用 git restore 回退单个文件（Git 2.23+ 推荐）
别再用 git checkout <commit> -- file.js</commit>，它已被标记为 deprecated，且语义模糊；git restore 明确表达“恢复文件”，不碰 HEAD、不触发分支切换。
- 恢复工作区和暂存区：
git restore --source=HEAD~3 src/api/client.ts - 只恢复暂存区（取消误
add）：git restore --staged package.json - 若提示
unknown option '--source'，说明 Git 版本 git checkout HEAD~3 -- src/api/client.ts（注意--不能省） - 执行后若文件没变化，运行
git check-ignore -v src/api/client.ts，确认它没被.gitignore或 submodule 排除
强制推送前必须确认的三件事
git push --force-with-lease 看似是 reset 后的必选项，但它不是无害操作——尤其在团队环境中。
- 确认远程分支保护已临时关闭（GitLab/GitHub 上需管理员权限），否则推送直接被拒
- 确认没有其他人在该分支上新推了提交，
--force-with-lease会失败并报错，这是它比--force安全的地方 - 推送完成后，立刻在远端平台把分支保护规则复原，否则下次有人
push可能覆盖关键提交 - 如果只是想“重置本地分支指向”，根本不需要推——比如调试时切到旧版测试，用
git switch -c test-old abc123f更干净
最常被忽略的是：回退动作本身不等于问题解决。比如用 revert 撤销了一个引入内存泄漏的提交，但那个泄漏可能已污染了数据库状态或缓存——代码回退了，环境未必同步回退。
