git revert -m 1 是撤销已推送合并提交的唯一安全方式，它通过创建反向新提交抵消变更而不改写历史；必须指定 -m 1 以第一个父提交（合并前主干）为基准，执行后需 git push 普通推送。
git revert -m 1 撤销已推送的合并提交
如果合并已经推送到远程（比如 main 或 develop），且其他人可能已基于它继续开发，git revert 是唯一安全的选择。它不改历史，只新增一个“反向提交”。
关键点在于：普通 git revert <commit> 对合并提交无效，必须加 -m 1 参数，告诉 Git 以第一个父提交（即被合并前的目标分支）为基准来计算反向变更。
- 先用
git log --oneline --graph找到那个合并提交的哈希值（比如a1daaad），确认它是 merge 类型（含两个 parent） - 执行
git revert -m 1 a1daaad，Git 会打开编辑器让你写提交信息，保存退出即可 - 此时工作区会应用反向修改，运行
git status可看到被撤销的文件变动 - 最后
git push origin <branch>—— 不需要--force，这是普通推送
git reset --hard + --force 推送的风险与前提
只有在确认没人拉取过错误合并、且你有权限强制覆盖远程时，才考虑 git reset。一旦远程分支被他人 fetch 过，强制推送会导致他们后续 pull 出现冲突甚至丢失工作。
- 本地重置前，务必用
git reflog或git log --oneline -10确认合并前最后一个安全 commit 的哈希（比如5b23503） - 执行
git reset --hard 5b23503后，所有合并引入的改动（包括中间的普通提交）全部消失 - 远程同步必须用
git push --force-with-lease origin <branch>，比--force更安全——它拒绝覆盖别人新推送的提交 - 若团队使用保护分支（如 GitHub 的 branch protection），
--force会被直接拒绝，这时只能切回git revert
撤销后再次合并同一分支的冲突问题
用 git revert -m 1 撤销合并后，如果想重新合并那个分支，Git 会提示“already up to date”，因为原合并提交仍存在，只是被抵消了。这不是 bug，是预期行为。
- 不要删掉 revert 提交，否则历史会混乱
- 正确做法是：先
git revert <revert-commit-hash>把撤销操作再撤销一次（即恢复被 revert 的内容） - 然后再
git merge <feature-branch>—— 此时 Git 能识别出这是全新合并，不再跳过 - 如果已有冲突，说明目标分支和 feature 分支都有新改动，需手动解决，不能依赖自动合并逻辑
如何判断该用 revert 还是 reset
核心就一条：看远程分支是否已被他人基于它工作。只要不确定，就选 git revert；只有在私有分支、或明确协调过所有人、或紧急修复线上问题且能立刻通知全员时，才用 reset。
-
git revert成本低：多一个提交，但历史清晰、协作安全 -
git reset成本高：省一个提交，但要求所有协作者同步执行git fetch && git reset --hard origin/<branch>，实操中极易遗漏 - CI/CD 流水线如果监听分支推送，
revert触发一次构建，reset + force-push可能触发两次（先删后增），需留意构建日志是否异常
git 命令自动判断。 
