撤销未推送的合并用 git reset --hard 回退到合并前提交；已推送则用 git revert -m 1 生成反向提交；误删分支可查 git reflog 恢复；冲突中断时用 git merge --abort 清理状态。
撤销未推送的合并：用 git reset --hard 回退到合并前提交
如果刚执行完 git merge，还没运行 git push，这是最干净的恢复方式。Git 会把当前分支 HEAD 直接指回合并前的最后一次提交，所有合并引入的更改都会从工作区和暂存区清除。
- 先确认合并前的位置：
git reflog查看历史操作，找到类似HEAD@{1}: merge feature-abc: Merge made by the 'ort' strategy.的上一条记录，记下其 commit hash（比如abc1234） - 执行重置：
git reset --hard abc1234 - 注意：
--hard会丢弃工作区和暂存区所有未提交变更，确保没有未保存修改再操作 - 如果合并时用了
--no-ff（生成了独立合并提交），git reset --hard HEAD~1也能快速回退，但仅限单次合并且无其他提交干扰
已推送的合并怎么撤？git revert -m 1 是安全选择
一旦 git push 完成，直接 reset 会改写公共历史，协作成员拉取时会出错。此时必须用 git revert 生成一个“反向提交”，不破坏历史线性，适合团队环境。
Git Changelog Generator
下载
使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……
-
git revert -m 1 <merge-commit-hash></merge-commit-hash>——-m 1指定保留主分支（通常是第一个父提交）作为基准，撤销另一分支带来的变更 - 例如合并提交是
def5678，运行git revert -m 1 def5678，Git 会创建新提交，内容是抵消那次合并的改动 - 如果合并涉及多个父提交（如三方合并），
-m 1和-m 2选错会导致还原不完整；用git show --pretty=raw <merge-commit></merge-commit>确认父提交顺序 - 生成的 revert 提交仍需
git push推送，其他人拉取后自动应用修复
误删分支后想找回合并前状态？查 git reflog 或 git fsck
有时候不是要撤销合并，而是合并后误删了原分支，又需要恢复某个旧状态。只要本地没执行过 git gc，Git 往往还留着那些“悬空”对象。
-
git reflog是首选：它记录所有 HEAD 变动，包括 checkout、merge、reset，哪怕分支被删，相关 commit 通常还在 reflog 里 - 如果 reflog 已清理（比如设置了
core.logAllRefUpdates=false），可尝试git fsck --lost-found扫描 dangling commit，然后用git show <hash></hash>确认是否为目标提交 - 找到 commit 后，用
git branch recovery-branch <hash></hash>重建分支，再基于它做 reset 或 cherry-pick - 远程分支删除不可逆，但只要本地还有对应 commit，就能重新
git push origin recovery-branch
合并冲突没解决完就退出，怎么清理残留状态
执行 git merge 后遇到冲突，手动退出或中断（比如 Ctrl+C），Git 会留下未完成的合并状态，后续操作（如 checkout、pull）会被阻止，提示 “You have unmerged paths”。这不是真正的合并完成，只是半截状态。
- 检查状态：
git status显示哪些文件仍在冲突中，同时.git/MERGE_HEAD文件存在 - 放弃合并：
git merge --abort—— 这是最稳妥做法，它会清理索引、工作区冲突标记，并删除MERGE_HEAD - 不要手动删
.git/MERGE_HEAD或.git/index，可能导致 Git 认为状态异常 - 如果
git merge --abort报错（如 index 锁定），先确认没其他 Git 进程在运行，再试一次
git tag 标记关键节点，比依赖 reflog 更可靠。
