误合并后安全回退：未提交冲突用git merge --abort；已提交未推送用git reset --hard HEAD~1；已推送则必须用git revert -m 1 HEAD生成反向提交。
git merge 误操作后怎么安全回退
合并出错最怕的是已提交又推送，但多数情况其实还卡在本地。关键看当前状态：
- 没提交冲突文件：直接
git merge --abort，所有改动清空，工作区回到合并前 - 已
git commit但没git push：用git reset --hard HEAD~1回滚这次合并提交（注意：会丢弃该次合并的所有变更） - 已
git push：别硬 reset，改用git revert -m 1 HEAD生成反向提交，这是唯一对协作友好的方式
特别注意：git reset --hard 在多人共用分支上是危险操作，一旦推送过，其他人再 pull 会遇到历史不一致问题。
冲突文件识别不准，IDE 显示和 git status 不一致
VS Code、JetBrains 等工具的“冲突检测”有时滞后或误报，真正可信的只有 Git 自身状态。
- 以
git status输出为准——只认 “both modified:” 开头的文件 - 快速过滤冲突项：
git status -s | grep "^UU"（UU表示 unmerged） - 想确认某文件是否真有冲突内容：
git diff --no-index --diff-filter=U或直接查git ls-files -u返回的 blob hash
编辑器里看到的“绿色波浪线”不等于 Git 认为的冲突；它可能只是你本地改了但还没 git add，或者冲突已解决但 IDE 缓存没刷新。
git merge 后提示 Already up to date 却没生效
这不是 bug，是 Git 的快进（fast-forward）机制在起作用——它没创建新提交，只是移动了分支指针。
- 执行
git merge feature后输出Already up to date，说明feature所有提交都已在当前分支中，无需合并 - 输出
Merge made by the 'ort' strategy才代表真正做了三方合并（生成了新提交） - 如果预期有新代码却没出现，先检查是否切错了目标分支（比如在
feature上 mergemain），再确认远程分支是否已git pull
别依赖终端有没有“卡住”来判断成败；每次 merge 后必须用 git log --oneline -n 5 看最新几条提交，确认目标分支指针是否真的前进了。
解决冲突后 git commit 失败，报 fatal: cannot do a partial commit during a merge
这个错误只有一种原因：你删掉了冲突标记，但没执行 git add 就直接 git commit。
- Git 把冲突文件视为“未合并路径（unmerged path）”，必须显式
git add才能把它从暂存区的冲突状态移出 -
git add .可以批量处理，但要小心把不该进本次合并的临时改动也加进去 - 如果改完发现逻辑不对，别强行 commit，立刻
git merge --abort重来
最容易被忽略的一点：即使你用 IDE 点了“Accept Current Change”或“Accept Incoming”，它也只是帮你删了标记，不会自动触发 git add ——这步永远得你手动敲命令。
