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提交前检查

在代码提交 git 前，通过 git diff 对比修改内容，逐文件审查变更点，检测潜在 BUG、隐含风险与可优化项，输出结构化审查报告。当用户表达提交前检查、提交检查、commit 前检查、pre-commit review、提前审查代码、检查一下改动、看看能不能提交等意图时使用此技能。注意：此技能与「代码评审」不同——代码评审在开发完成后结合需求文档与概要设计进行完整度审查，提交前检查是轻量级的基于 git diff 的代码质量把关。

下载

• 只要远程分支没被别人同时推送新提交，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 提交可能无法真正“撤回”那些操作——得配合人工补偿逻辑。