如何撤销已推送的合并提交（merge commit）
撤销已推送的合并提交：git revert -m 1 <合并提交哈希>，-m 1 指定以主线（通常是 main）为基准做反向操作。注意：之后想把该分支重新合回来，需要先 revert 这个 revert 或重建分支提交。
用 git revert -m 1 <合并提交哈希>。合并提交有两个或更多父提交，-m 1 告诉 Git"以第一个父（主线，通常是 main）为基准"，生成一个反向应用合并提交相对所选父提交差异的新提交。共享历史通常应优先用 revert；它保留历史但仍需检查代码效果与冲突，不能称为零风险。
操作步骤
git log --oneline --graph # 找到合并提交（Merge branch 'feature-x'）
git show -s --format=%P a1b2c3d # 先确认父序号与要保留的基线
git revert -m 1 a1b2c3d
# 解决可能的冲突后提交
git push
-m 1 的 1 指"第一个父提交"。git show <合并提交> 能看到父提交顺序，一般第一个是合入目标（main）。
大坑：之后想重新合并该分支
revert 合并后，Git 认为该分支的改动"已经合并过"——你修复完想再次合并时，原先已被撤销的祖先改动不会仅因再次合并而自动恢复，后续新提交仍可能合入！解决办法二选一：
# 方案一：revert 那个 revert（制造"重新引入"提交）
git revert <之前的revert提交>
git merge feature-x # 现在能正常合了
# 方案二：从最新 main 建新分支，显式重新实现或经审阅地重放需要的改动
# 普通 git rebase main 可能跳过已在祖先中的原提交，不能保证重新引入被 revert 的内容
常见问题（FAQ）
Q：直接 reset 删掉合并提交强推行不行？
技术上可以（未被别人拉取时），但共享分支强推是协作红线。revert 保留已有历史，但仍改变业务代码、可能冲突，需验证并协调。
Q：revert 合并提交为什么经常冲突？
revert 要反向应用的改动面大（整个分支），期间主线又前进了很多，冲突概率高。耐心解，或重新评估需撤销的范围，不能用普通 rebase 当作通用修复。
Q：-m 参数怎么确认用 1 还是 2？
git log -1 --format='%P' <合并提交> 列出父提交，第一个是 1。对 "merge feature into main" 的提交，1=main 侧——保留它、撤销另一侧。
