一次 Git Rebase 事故，让我彻底明白 Rebase 和 Merge 的区别

前言

事情的起因是这样的：上周我在项目里用 git rebase 整理分支，结果把同事的提交“消失”了，虽然最后通过数据恢复救了回来，但整个过程大家都吓出一身冷汗。这次惊险的事故，让我不得不沉下心去深究 rebase 和 merge 的底层差异，以及它们在不同协作场景下的正确用法——毕竟“知其然更知其所以然”，才能避免再踩类似的坑。

一、先还原“事故现场”

要理解问题的根源，先从当时的分支场景说起：

我们项目的分支结构很简单：

• main 分支是主分支，同事在上面修复了一个紧急 bug，提交历史是 A → B → C（其中 C 是 bug 修复提交）；
• 我在 feature 分支开发新功能，基于 main 的 B 提交开始，提交了 D 和 E 两个功能代码，分支关系如下：

  main:    A --- B --- C (bug 修复)
         \
  feature:    D --- E (你的新功能)

当时我想把 main 分支的 bug 修复同步到 feature 分支，觉得 rebase 能让提交历史更整洁，就直接执行了以下命令：

git checkout feature  # 切换到自己的feature分支
git rebase main       # 基于main分支做rebase

执行后，分支历史确实变成了“直线”，feature 分支的 D、E 提交被“搬到”了 main 最新的 C 提交之后，看起来很清爽：

main:    A --- B --- C
                        \
feature:                 D' --- E'  # D'、E'是rebase后生成的新提交（ID已改变）

但问题出在：我执行 rebase 前，没有先拉取远程 main 分支的最新代码（当时本地 main 分支还是旧的 B 提交），且在解决冲突时误删了同事 C 提交里的代码。更糟的是，我直接用 git push -f 强制推送了 feature 分支到远程，导致远程分支的历史被覆盖——同事的 bug 修复提交 C，在远程仓库里“凭空消失”了。

二、rebase 和 merge 到底有什么区别？

事故后我翻遍了 Git 官方文档，也对比了两种命令的实际执行效果，终于理清了它们的核心差异：本质是“是否修改提交历史”，以及“如何处理分支合并”。

1. git merge —— 历史完整，简单安全

merge 的核心逻辑是“保留分支历史，创建新的合并提交”，它不会改动任何已有的提交记录，相当于在两个分支的最新节点之间“架一座桥”。

执行命令

比如要把 main 分支的更新同步到 feature 分支：

git checkout feature  # 切换到需要接收更新的分支
git merge main        # 合并main分支的内容

分支历史变化

合并后会生成一个新的“merge commit”（通常标记为 M），分支历史会保留原来的“分叉”结构：

A --- B --- C ------ M (merge commit，新生成)
 \              /
  D --- E -----        # feature分支的原有提交不变

核心特点

• 不修改历史：所有原有提交（A、B、C、D、E）的 ID 和内容都不会变，绝对安全；
• 冲突处理简单：即使有代码冲突，只需要在创建 merge commit 时解决一次，后续不会再重复出现；
• 历史可追溯：从提交记录能清晰看到“哪个分支在什么时候合并了什么内容”，适合团队协作追溯问题。

2. git rebase —— 历史干净，但会改动历史

rebase 的核心逻辑是“改写提交历史，让分支看起来像直线开发”，它会把当前分支的所有提交，“重新基于”目标分支的最新提交排列，相当于“擦掉”原来的提交记录，再重新生成新的提交（即使内容相同，提交 ID 也会改变）。

执行命令

同样是同步 main 分支到 feature 分支：

git checkout feature  # 切换到自己的分支
git rebase main       # 基于main的最新提交，重排feature的提交

分支历史变化

feature 分支的 D、E 提交会被“移动”到 main 最新的 C 提交之后，生成新的 D'、E' 提交，最终历史变成一条直线：

A --- B --- C --- D' --- E'  # 没有分叉，历史整洁

核心特点

• 修改历史：原有提交（D、E）会被替换为新提交（D'、E'），提交 ID 改变——这是最危险的点；
• 冲突处理复杂：如果多个提交都和目标分支有冲突，需要逐个提交解决（比如 D 冲突解决完，还要处理 E 的冲突）；
• 历史整洁：分支记录没有“分叉”，看起来像是从目标分支直接开发的，适合整理个人分支的提交记录。

三、各自的安全使用场景

搞清楚差异后，关键是要知道“什么时候该用哪个”——选对场景，才能既发挥它们的优势，又避免风险。我整理了一张场景对比表，覆盖了日常开发中最常见的情况：

四、如何避免 rebase 导致代码丢失？

这次事故让我总结出几个“rebase 安全守则”，只要遵守这些规则，就能大幅降低风险：

1. 绝对不在公共分支上用 rebase
   公共分支（如 main、dev）是所有人协作的基础，一旦用 rebase 改写历史，会导致整个团队的分支混乱。如果需要同步公共分支的更新，用 merge 而非 rebase。

2. rebase 前先拉取远程最新代码
   执行 rebase 前，一定要先通过 git fetch 获取目标分支的最新状态，避免基于旧版本做 rebase（这是我这次踩的核心坑）：

   git fetch origin  # 拉取远程所有分支的最新代码
   git rebase origin/main  # 基于远程main的最新版本做rebase，而非本地旧版本

3. 解决冲突时逐行检查，不盲目删除
   rebase 冲突时，Git 会提示“哪些文件有冲突”，打开文件后，一定要仔细对比冲突部分的代码——尤其是同事的提交，确认无误后再保留，避免手滑删错代码。

4. rebase 出错时，立即用 --abort 回滚
   如果在 rebase 过程中发现不对劲（比如冲突太多，或者误删了代码），只要还没执行 git rebase --continue，就能用以下命令彻底回滚到 rebase 前的状态：

   git rebase --abort  # 紧急回滚，救了我好几次

5. 推送前检查提交历史和差异
   推送分支前，先用以下命令确认提交历史是否正确，代码差异是否符合预期：

   git log --oneline --graph --decorate  # 查看分支历史的图形化结构
   git diff origin/feature  # 对比本地feature分支和远程feature分支的差异

五、我的经验总结

经过这次事故，我对 merge 和 rebase 有了更通俗的理解：

• merge 像是在账本上“追加记录”——不管之前的记录怎么分，新记录会明确写清“合并了哪部分内容”，不动旧账，安全可靠，但账本可能会有点乱；
• rebase 像是在“修改旧账本”——把之前的记录重新整理成整齐的顺序，账本变干净了，但如果改的时候不小心擦错了，旧记录可能就找不回来了。

最后想分享一句心得：Git 是个很宽容的工具（很多操作都能回滚），但对“提交历史”的操作必须心存敬畏。代码丢失不可怕，可怕的是不知道为什么会丢。只有真正理解 merge 和 rebase 的底层逻辑，才能在团队协作中既保持高效，又避免给同事“挖坑”。

除非注明，否则均为李锋镝的博客原创文章，转载必须以链接形式标明本文链接

本文链接：https://www.lifengdi.com/others/4518