刚合并完冲突就发现错了且未推送，应立即用 git reset --hard HEAD@{1} 回退到合并前状态；若已推送，则必须用 git revert -m 1 <hash> 生成反向提交，避免重写历史。
刚合并完冲突就发现错了，还没 push 怎么办
立刻停手，别提交、别推送。这时候错误只在你本地，回滚成本最低。
Git 的 git reset --hard HEAD@{1} 是最直接的解法——它会把你拉回到执行 git merge 前的那个状态，包括工作区和暂存区全部还原。这个操作依赖 reflog 记录，而 Git 默认开启，所以基本不会失效。
- 先确认当前分支没其他新提交：
git reflog看一眼，找到带merge字样的上一条记录，通常就是HEAD@{1} - 如果合并后你又顺手改了点东西、甚至
git add了，HEAD@{1}可能不准，得用git log --oneline -n 10找到 merge 提交的父提交（第一个 parent），再git reset --hard <commit-hash> -
--hard会丢弃所有未提交改动，执行前务必git status确认工作区干净；否则先git stash存起来
已经 push 了，别人可能已经 pull 过怎么办
不能硬重置，否则会重写历史，导致队友下次 git pull 时出现“non-fast-forward”报错，甚至丢失他们自己的提交。
必须用 git revert 生成一个反向提交来抵消合并效果。关键在 -m 1 参数：它告诉 Git 以当前分支（即被合并进来的那个主干）为基准还原，而不是以被合并分支为基准——选错就等于把代码往错方向再翻一遍。
- 先定位 merge 提交：
git log --oneline --merges -n 5，找最近那条带Merge branch 'feature/xxx'的记录 - 执行：
git revert -m 1 <merge-commit-hash>，Git 会自动打开编辑器让你写 revert 提交信息 - 如果 merge 提交有多个 parent（比如三方合并），不确定哪个是主干，先运行
git show --pretty=raw <hash>查看parent行顺序，第一行是-m 1，第二行是-m 2 - revert 后记得
git push，其他人拉取后会看到一条明确的Revert "Merge branch..."提交，历史可追溯
merge 提交里混了不该进来的代码，只想撤掉部分改动
Git 不支持“部分 revert merge”，但你可以绕过 merge 提交本身，直接 revert 它引入的具体变更。
GInstall OneClick — 一键安装 GitHub 项目：规划、克隆、安装 Node 依赖、运行开发脚本。适用于想要获取 GitHubNode.js 项目的用户。
本质是把 merge 提交当做一个普通提交来看待，找出它带来的净修改（diff），然后对这些文件做选择性 revert。这适合那种“合并时没注意，结果把调试日志、临时配置一起合进去了”的场景。
- 先看 merge 提交改了哪些文件：
git diff <merge-commit-hash>^1 <merge-commit-hash>（^1指第一个 parent） - 对单个文件 revert：
git revert <merge-commit-hash> --no-commit --no-edit -- <file-path>，它会把该文件的变更逆向应用，但不自动提交 - 检查结果：
git status和git diff，确认只撤掉了想撤的部分，再git commit -m "Revert unwanted changes from merge" - 注意：如果文件在 merge 后又被改过，这个操作可能冲突，得手动解决
撤销后发现 revert 提交本身也错了，怎么 undo revert
revert 本身是个普通提交，所以 undo 它的方式和其他提交一样：再 revert 一次。不是 “revert revert”，而是 “revert the revert commit”。
这跟 git reset 不同，git revert 的链式操作天然可逆，且每一步都留痕。但要注意，如果你 revert 的是一个 merge 提交，第二次 revert 仍需带 -m 1，否则语义会反转。
- 找到 revert 提交的 hash：
git log --oneline | grep "Revert" - 执行：
git revert <revert-commit-hash>，它会重新把之前被 revert 掉的代码加回来 - 如果原 merge 是
-m 1revert 的，这次 revert 这个 revert 提交时，-m 1依然要带上，否则 Git 会误以为你想 revert 第二个 parent - 多人协作中，这种“revert → revert revert”链条容易让人困惑，建议在提交信息里写清楚动机，比如
Revert "Revert merge..." because X
真正容易被忽略的点是：merge 提交的 parent 顺序不是按时间排的，而是按 git merge 命令里参数顺序定的——git merge feature 时，当前分支是 ^1，feature 是 ^2。很多人凭直觉猜 -m 1，结果一 revert 就把主干代码删了。动手前，git show --pretty=raw 多看一眼，比什么都靠谱。
