git revert 是新增反向提交而非删除历史，保留原始提交以确保安全可追溯；需注意合并提交加 -m 1、推送前先拉取、禁用 reset --hard 于共享分支。
revert 会生成新提交，不是删除历史
很多人以为 git revert 是“撤回”操作，其实它是在当前分支上新增一个反向提交，把目标提交的修改内容抵消掉。这意味着原始提交依然保留在历史中，远程仓库里也能看到它——这是安全的前提，也是它适合线上环境的原因。
常见错误现象：git revert 后发现代码没变、或者报错 error: Commit XXX is a merge but no -m option was specified，本质是没处理好合并提交或冲突未解决。
- 单个普通提交：直接用
git revert <commit-hash></commit-hash> - 多个连续提交：用范围语法
git revert <oldest>^..<newest></newest></oldest>（注意^表示排除起点） - 合并提交必须加
-m 1指定主干父提交，否则 Git 不知道该“撤销谁的变更” - revert 后必须
git push推送新提交，否则远程看不到变化
revert 后 push 被拒？因为远程已有你本地没有的提交
执行 git revert 并 git push 时出现 ! [rejected] main -> main (non-fast-forward)，说明别人在你 revert 前又推了新提交。这不是 revert 本身的问题，而是推送前没同步最新远程状态。
正确做法永远是：先拉取再 revert 再推送。顺序错了，轻则 push 失败，重则引入重复 revert 提交。
- 执行
git pull origin main（确保本地有最新历史） - 再做
git revert，避免基于过期基线操作 - 如果已 revert 完但 push 被拒，别硬 push -f，先
git pull --rebase整理本地提交顺序 - revert 提交也参与 rebase，所以
git pull --rebase后可能要手动解决 revert 引入的冲突
revert 合并提交必须指定主干父提交（-m 1）
当你 revert 一个由 git merge 产生的提交时，Git 会报错 Commit XXX is a merge but no -m option was specified。因为合并提交有两个父提交：一个是当前分支的前一个提交（主干），一个是被合并进来的分支头（feature）。revert 需要知道“以谁为基准来反向计算差异”。
-m 1 表示以第一个父提交（即合并前的主干）为基准；-m 2 则是以被合并的分支为基准——绝大多数情况你要的是 -m 1。
- 查证合并提交结构：用
git show --pretty=raw <commit-hash></commit-hash>看parent行顺序 - 安全写法：总是先
git revert -m 1 <merge-commit-hash></merge-commit-hash>，除非你明确想撤销整个 feature 分支引入的所有变更 - 如果误用了
-m 2，生成的 revert 提交逻辑相反，可能把不该删的代码删掉，且后续难以直观识别
revert 不等于 reset，别在 shared 分支上用 reset --hard
有人遇到线上问题，第一反应是 git reset --hard HEAD~1 然后 git push --force。这在共享分支（如 main、prod）上极其危险：它会改写历史，导致其他协作者的本地仓库和远程不一致，引发各种奇怪的冲突和丢失提交。
revert 是唯一被设计用于“已推送代码”的安全回退方式。reset 只适用于你本地还没 push 的场景，或者私有功能分支上自己清理中间提交。
- 只要提交已经
git push到远程，就放弃所有reset+--force思路 - 团队协作中，
git revert是唯一可审计、可追溯、不影响他人工作流的方案 - 如果你发现某次 revert 本身有问题（比如漏改、冲突没解对），应该再 revert 那个 revert 提交，而不是试图 reset 它——越补越乱
真正容易被忽略的是：revert 提交的 message 默认带 “Revert” 前缀，但很多团队要求补充上下文，比如 Jira ID 或故障编号。不写清楚，半年后没人知道这个 revert 当初对应哪次线上事故。
