问题的核心场景在 Chromium 这样的超大型开源项目开发中我们经常需要将特性分支A的代码合并到主线分支B。理想情况下一切顺利。但现实中冲突解决是最大的风险点。你遇到的典型情况1. 将 A 分支合并到 B 分支2. 解决了一堆冲突3. 编译通过了表面上万事大吉4. Push 到 Gerrit5. 后来发现大量代码被还原了——在解决冲突时错误地选择了上游或下游的版本导致自己的业务逻辑被覆盖此时你需要的不是零散的命令而是一套完整的诊断-决策-执行流程。第一步诊断合并方式——这是所有操作的前提Git 的合并有本质不同的两种路径merge 和 rebase。它们的回退方式天差地别。你必须先搞清楚自己用的是哪种。执行命令bashgit log --oneline --graph -20场景判断Merge 的特征如果你看到这样的拓扑结构* a1b2c3 Merge branch A into B|\| * xxxx (A分支的提交)| * yyyy* | zzzz (B分支原有的提交)结论这是 merge。 它创建了一个明确的合并提交merge commit有两个父节点。场景判断Rebase 的特征如果你看到的是一条直线* eeee (rebase后的A提交)* dddd* cccc* bbbb (B分支原有的提交)结论这是 rebase。 A 分支的提交被“重放”在 B 分支的最新提交之上历史呈线性没有合并提交。第二步根据诊断结果选择回退策略情况一Git Merge 的回退最安全可控场景假设B1---B2--------M (B分支)\ /A1---A2M 就是那个有问题的合并提交。方案 A尚未 Push理想情况如果你在 git push 之前就发现了问题直接用硬重置bashgit reset --hard HEAD~1这会撤销合并提交 MB 分支回到 B2 的状态就像什么都没发生过。方案 B已经 Push 到远端团队开发的标准做法绝对不要用 git reset git push --force除非这个分支只有你一个人在用。在团队协作中这会给同事带来灾难。正确的做法是反向提交revert the mergebashgit revert -m 1 merge_commit_sha# 例如git revert -m 1 a1b2c3这里 -m 1 是关键参数它告诉 Git我们要以主线分支B 分支为保留对象撤销由合并操作引入的所有变更。这个命令会生成一个新的 commit其内容刚好与合并操作相反。优点· 不改写已发布的历史· 对 Gerrit 和其他协作者完全安全· 是可追踪的、明确的“撤销”操作情况二Git Rebase 的回退更隐蔽更常见于 GerritRebase 后没有 merge commit所以 git revert -m 无效。场景假设原始状态B1---B2 (B)\A1---A2rebase 后B1---B2---A1---A2 (B)关键救命工具git reflogreflog 记录了你在本地仓库中的所有 HEAD 移动历史包括那些在 git log 中不可见的、被抛弃的提交。它是你后悔药的生产地。执行bashgit reflog -10你会看到类似输出a1b2c3d HEAD{0}: rebase (finish): returning to refs/heads/Be4f5g6h HEAD{1}: rebase (pick): A2i7j8k9l HEAD{2}: rebase (pick): A1m0n1o2p HEAD{3}: rebase (start): checkout m0n1o2pq3r4s5t HEAD{4}: commit: B2记下 rebase 之前的 commit这里是 HEAD{4} 或直接记下其 SHA q3r4s5t。方案 A该分支只有你一个人可以强力重写历史bash# 直接硬重置到 rebase 前的状态git reset --hard HEAD{4}# 或 git reset --hard q3r4s5t# 强制推送git push --force-with-lease--force-with-lease 比 --force 安全它会检查远端分支是否在你拉取之后有别人推送了新提交从而防止你意外覆盖他人的工作。方案 B已经有人基于你 rebase 后的分支开发更安全此时不能 reset。你需要用“反向打补丁”或者“逐个撤销 rebase 来的提交”的方式。方法一反向 diff 生成补丁bash# old_sha 是 rebase 前的提交git diff HEAD old_sha rollback.patchgit apply rollback.patchgit commit -m Rollback wrong rebase conflict resolution这个方法会把工作区恢复到 rebase 前的状态并提交为一个新的 commit。方法二逐个 revert如果 rebase 产生的提交不多A1、A2可以直接 revert 它们bashgit revert A2_shagit revert A1_sha注意 revert 的顺序是倒序的。更精细的方案不全盘回退只恢复被误覆盖的文件你已经解决了大量冲突、通过了编译可能其中只有一部分冲突是解错的。全盘回退代价太大。推荐流程1. 创建备份分支以防万一bashgit branch backup_before_rollback2. 定位被“还原”的文件找到合并前的那个 commit通过你之前记下的或 reflog 找到的 old_sha。bash# 查看哪些文件被改动了以及改动规模git diff old_sha HEAD --stat3. 精确恢复如果确认是某几个文件被错误覆盖了就直接从旧版本中检出它们bash# 从合并前的提交中恢复指定文件到当前工作区并暂存git checkout old_sha -- path/to/your/file1.cc path/to/your/file2.hgit commit -m Restore incorrectly overwritten files during merge核心教训冲突解决的元认知“代码被还原”的根源99% 是在解决冲突时的误操作 HEADZero Browser 新逻辑 你的修改Chromium 原生逻辑 上游的修改 A你错误地选择了 theirs 或者手动删除了自己的逻辑。代码结构没破坏编译自然通过但业务功能丢失了。完整操作清单面对大型仓库我会这样做1. 瞬间保护现场git branch backup_$(date %Y%m%d_%H%M%S)2. 诊断执行 git log --oneline --graph -15 和 git reflog -10判断是 merge 还是 rebase定位“合并前”的提交点。3. 评估影响范围git diff old_sha HEAD --stat判断是 10 个文件还是 500 个文件被毁。4. 决策与执行· 少量文件被误覆盖精准 checkout 恢复推荐首选。· 整个合并/变基严重失败根据 merge/rebase 类型选择 git revert -m 1 或 reset/反向补丁方案。5. 推送并沟通将回退操作 push 到 Gerrit并在变更说明中清晰解释发生了什么以及你采取了什么恢复措施。最后永远记得在开始任何可能改变历史或复杂的合并操作前先记下当前的 HEAD SHA 或执行一次 git branch。这个习惯会在关键时刻救你一命。