最安全回退未推送的 merge 是用 git reset --hard head@{1}；已推送则用 git revert -m 1 ；删分支后可用 git log --all 查 commit 恢复；预防建议用 --no-ff 合并并提前检查分支状态。
回退未推送的 merge 操作（本地还没 git push）
如果刚执行完 git merge，还没推送到远程，最安全的方式是直接用 git reset 回退到合并前的状态。关键看是否保留合并提交——用 --hard 会丢弃所有合并引入的改动，--mixed（默认）则保留工作区修改，方便检查。
- 确认当前分支和合并前的提交：运行
git reflog，找到 merge 前那条记录，比如HEAD@{1} - 硬重置（推荐多数情况）：
git reset --hard HEAD@{1}，立刻回到合并前干净状态 - 如果合并后已做了其他提交，不能只靠
HEAD@{1}，得先用git log --oneline -n 20找到合并提交的父提交（通常是第一个 parent），再git reset --hard <commit-hash></commit-hash> - 注意：重置后若之前有未暂存的修改，会被一并丢弃；建议重置前先
git status确认工作区干净
撤销已推送的 merge 提交（远程已有该 commit）
一旦 git push 过去，就不能用 git reset 直接删掉远程历史（除非强制推送且团队允许）。此时应使用 git revert 生成一个“反向提交”，安全抵消 merge 效果。
- 找到 merge 提交的 hash（如
a1b2c3d），运行：git revert -m 1 a1b2c3d；-m 1表示以第一个 parent（即当前分支主干）为基准还原，这是关键参数，漏掉会导致 revert 失败或逻辑错误 - revert 后会生成新提交，需
git push上去；其他人拉取后会看到这个 revert 提交，历史保持线性可追溯 - 如果 merge 提交有多个 parent（比如三方合并），
-m 1和-m 2选错会导致还原内容相反——通常主干是-m 1，被合并分支是-m 2，不确定时先git show --pretty=raw <merge-commit></merge-commit>查 parent 顺序
误删 merge 后的分支，但想找回合并内容
有时候执行了 git branch -d <branch-name></branch-name>，以为删掉了代码，其实只是删了分支指针，合并进来的 commit 仍存在于主干历史中。只要没做 git gc 或长时间无人引用，就能恢复。
- 先查有没有残留引用：
git reflog show <target-branch></target-branch>（如果记得分支名）或git fsck --lost-found扫描悬空对象 - 更常用的是：
git log --all --grep="keyword" --oneline，用合并时的 commit message 关键字定位 - 找到对应 commit hash 后，可新建分支指向它：
git branch recovered-branch <hash></hash>，再git checkout检出验证 - 注意：
git branch -D（大写 D）是强制删除，不会进 reflog，恢复难度陡增；日常尽量用-d（小写）让 Git 帮你判断是否安全
预防下次再 merge 错：用 --no-ff 和预检
默认 fast-forward 合并不产生 merge commit，导致历史扁平、难以识别合并边界；而 --no-ff 强制生成 merge commit，配合良好命名，能大幅降低回退时的判断成本。
- 日常合并建议统一用：
git merge --no-ff --edit <branch-name></branch-name>，编辑 commit message 加上 Jira ID 或简要说明 - 合并前必做两件事：
git fetch origin更新远程信息，再git log --oneline --graph --all直观查看分支关系，避免“本地以为干净，其实远端已有新提交” - 团队可配置 pre-merge hook 检查目标分支是否保护分支、是否包含冲突标记等，但简单场景下，养成
git status+git diff ...origin/main的习惯更实在
真正麻烦的不是怎么回退，而是 merge 提交里混了不该有的改动、或者 revert 时选错了 parent——这两处没留心，补救成本远高于预防。操作前多看一眼 git show <commit></commit>，比事后翻 log 强十倍。
