公共分支上已推送的提交禁用git reset，必须用git revert安全回滚：它新增反向提交而非改写历史，避免协作断裂；撤销合并需加-m 1参数，且须确认目标提交状态、敏感变更及团队规范， revert后须立即跟进修复。
公共分支上已经 push 的提交，不能用 git reset
因为 git reset --hard 会直接删掉历史记录，远程仓库一旦被强制推送（git push --force），其他协作者再 git pull 就会遇到冲突、丢失提交，甚至本地分支彻底错乱。这不是“撤销”，是“强拆历史”。团队里只要有人执行过一次 git push --force 覆盖了 main 或 develop，后续所有人的 git status 都可能显示“ahead of origin”，但实际拉不到新内容——这是 Git 分布式模型下最典型的协作断裂现象。
git revert 是唯一安全的回滚方式
它不改历史，只加一条“反向提交”：把你要撤销的那个 commit 里新增的代码删掉、删掉的代码加回来，然后作为一个新 commit 推上去。别人拉代码时完全无感，历史线性可读，CI/CD 流水线也不会因哈希变化而中断。
-
git revert <commit-hash></commit-hash>撤销单个提交（推荐先用git log --oneline --decorate -n10确认 hash） - 如果要撤销合并提交（比如一个 feature 分支合进
main），必须加-m 1参数：git revert -m 1 <merge-commit-hash></merge-commit-hash>，否则 Git 不知道该以哪个父提交为基准生成反向逻辑 - 冲突不可避免：revert 过程中如果被撤销的代码和当前 HEAD 有重叠修改，Git 会停住并标出冲突文件，解决后
git add+git revert --continue - 不要
git revert --abort后反复试——每次 abort 都会留下一个空的 revert 提交，污染历史；建议先在本地建临时分支（git branch revert-test）验证通过再操作主分支
撤销前必须确认三件事
很多人 revert 失败，不是命令错了，是没看清上下文：
- 目标 commit 是否已合并到其他分支？如果已合入
release/v2.3，只 revertmain会导致两个分支行为不一致 - 这个 commit 是否包含敏感变更（如数据库迁移脚本、配置开关）？revert 只处理代码，不自动回滚数据库或外部状态
- 团队是否已有约定：revert 提交必须带明确 message 格式？例如
revert: [BUG-123] fix user login timeout (reverts a1b2c3d)，方便后续审计和自动化识别
真正容易被忽略的点：revert 之后的修复必须跟上
revert 解决的是“紧急止损”，不是“问题终结”。你撤回了一个导致 CI 失败的提交，不代表那个 bug 不存在了——它还在原地，只是没被 merge 进来。第二天如果有人基于旧 commit 继续开发，或者另一个分支又把同样逻辑合进来，问题照旧复现。所以 revert 后第一件事，不是庆祝，而是立刻开一个 bugfix/xxx 分支，定位根因、补测试、写清楚修复依据，并关联到原始 issue。否则，revert 就只是给历史多贴了一张“此路不通”的便签，而不是真正修好了路。
