git revert 创建新提交来反向抵消原提交变更，不删除历史；适用于已推送的共享分支，需注意多提交撤销顺序、冲突处理及副作用补偿。
revert 会创建新提交，不是删除原提交
很多人误以为 git revert 是“撤回”或“删掉”某次提交，实际它是在当前分支上新增一个**反向操作的提交**，把原提交的变更内容抵消掉。这保证了历史线性、可追溯，也避免了 git reset --hard 那种重写历史带来的协作风险。
适用场景：已推送到远程（尤其是多人共用分支）、不想破坏提交时间线、需要留痕审计。
- 如果目标提交是
abc1234，运行git revert abc1234后，会生成一个新提交，其 commit message 默认为Revert "xxx" - 该操作只影响工作区和暂存区的文件状态，不会动 HEAD 指针之前的提交记录
- 若原提交修改了 3 个文件，revert 提交也会精准地把这 3 个文件改回原状（按 diff 反向应用）
撤销多个提交时注意顺序和范围
连续撤销多个提交，顺序反了会出问题。比如想撤销 HEAD~2 到 HEAD（即最近三次提交），不能写成 git revert HEAD~2 HEAD——Git 会报错或理解成单次提交范围。
- 正确做法是：从**最旧到最新**依次 revert，例如
git revert abc1234 def5678 ghi9012 - 更常用的是用波浪号范围：
git revert abc1234^..ghi9012（注意^表示“不包含起始提交”，等价于abc1234...ghi9012） - 如果中间某个 revert 引发冲突（比如后续提交又改了同一行），Git 会暂停并提示你手动解决，解决后
git add . && git revert --continue
revert 后 push 需要强制吗？一般不需要
git revert 本身只是新增提交，所以 git push 是普通快进推送，无需 --force。这点和 reset 有本质区别。
- 只要远程分支没被别人同时推送新提交，
git push origin main就能成功 - 如果 push 被拒，大概率是别人先推了——此时应先
git pull，再检查 revert 提交是否仍适用（有时合并后 revert 内容已失效） - 极少数情况：你 revert 的是一个 merge 提交，需加
-m 1指定主线路，否则 Git 不知道该“撤销哪条路径”的变更
revert 后还能再 revert 吗？可以，但要小心
对一个 revert 提交再次 revert，等于把原始变更“恢复回来”。这种操作合法，但容易绕晕人，尤其在团队协作中。
- 假设 A 提交加了一行代码，B 是
git revert A，C 是git revert B→ C 的效果等同于重新应用 A 的改动 - Git 不会阻止你这么做，但日志里会出现一串 “Revert ‘Revert …’” 嵌套，可读性差
- 如果只是为了临时修复，建议用
git cherry-pick或直接改代码，而不是靠 revert 套娃
真正容易被忽略的是：revert 提交本身也会被 CI/CD 流水线触发构建，如果原提交引入了数据库迁移或外部副作用，仅靠 revert 提交可能无法真正“撤回”那些操作——得配合人工补偿逻辑。
