未推送时用 git reset 回退最直接：--hard 彻底丢弃合并提交，--merge 保留工作区修改；已推送则必须用 git revert -m 1 生成反向提交；误删分支可通过 reflog 恢复；合并冲突未完成可用 git merge --abort 放弃。
合并后还没推送到远程，用 git reset 回退最直接
只要本地合并完没执行 git push，就还在可控范围内。此时 git reset 是最快、最干净的方式。
关键看你想回到哪个状态：
- 想彻底丢弃合并提交（包括合并产生的新 commit），用
git reset --hard HEAD~1（假设合并只产生一个 commit） - 想保留工作区修改（比如合并后手动改过文件），用
git reset --merge HEAD~1，它会安全地撤回合并，又不丢你的编辑 - 不确定合并提交占几个 commit？先运行
git log --oneline -n 5看清楚 HEAD 往前数几条才是合并前的节点
注意：--hard 会清空暂存区和工作区，别在有未保存修改时乱用；--merge 更稳妥，是 Git 官方推荐的“撤销合并”方式之一。
已经推送到远程，必须用 git revert 而不是 reset
一旦 git push 过去，其他人可能已基于那个合并继续开发。此时用 reset 强制覆盖历史，会破坏协作基础——别人 pull 时会遇到冲突甚至丢失提交。
正确做法是用 git revert 生成一个「反向操作」提交：
openclaw-gitcode-pr-monitor
下载
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
- 找到合并提交的 hash（比如
abc1234），运行git revert -m 1 abc1234 -
-m 1表示“以第一个父提交为基准”，这是撤销合并的关键参数；漏掉它会报错revert is not possible because you have unmerged files - 如果合并涉及多个分支，且你想一并撤销后续所有衍生提交，得逐个
revert，不能靠一次命令解决
生成的 revert 提交可以正常 push，不影响他人工作流，但会让历史看起来略臃肿——这是协作代价。
误删分支后想找回合并前的原始分支
Git 删除分支只是删掉一个指针，只要那些 commit 还没被 GC 清理，就能恢复。
- 先查操作日志：
git reflog，找删除前该分支最后一次指向的 commit（比如显示abc1234 HEAD@{2}: checkout: moving from feature-x to main） - 用
git branch feature-x abc1234重建分支 - 如果 reflog 已清理或记不清 hash，试试
git fsck --lost-found找孤立 commit，再用git show <hash></hash>确认内容
reflog 默认只保留 30 天（或 90 天，取决于配置），所以发现误删要尽快操作；远程分支删了，本地 reflog 依然有效。
合并冲突没解决完就退出，导致分支状态混乱
这种情况常见于 git merge 过程中遇到冲突，手动编辑后忘了 git add 和 git commit，直接关了终端——结果分支卡在「未完成合并」状态，后续任何 checkout 或 pull 都会报错。
- 先确认状态：
git status会提示you have unmerged paths或merging - 想放弃这次合并：
git merge --abort（Git 2.0+）；老版本用git reset --merge - 想接着解决：把冲突标记删掉、改好文件 →
git add <file></file>→git commit（不要加-m，Git 会自动填合并提交模板）
别手动生成 commit 或强行 reset --hard，否则可能留下 .git/MERGE_HEAD 文件残留，导致后续命令持续报错。
