事情的起因是这样的：上周我在项目里用 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，在远程仓库里“凭空消失”了。
事故后我翻遍了 Git 官方文档，也对比了两种命令的实际执行效果，终于理清了它们的核心差异：本质是“是否修改提交历史”，以及“如何处理分支合并”。
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 时解决一次，后续不会再重复出现；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 的冲突）；搞清楚差异后，关键是要知道“什么时候该用哪个”——选对场景，才能既发挥它们的优势，又避免风险。我整理了一张场景对比表，覆盖了日常开发中最常见的情况：
| 场景 | 推荐方式 | 原因 |
|---|---|---|
| 本地分支开发，还没 push 到远程 | rebase | 本地分支的提交只属于自己，用 rebase 整理历史（比如合并零散的“修复bug”提交），后续合并到主分支更清晰 |
| 拉取远程更新，不想生成多余 merge commit | pull --rebase | 用 git pull --rebase origin main 替代 git pull，避免每次拉取都生成一个无用的 merge commit，保持本地历史整洁 |
| 分支已 push 到远程，且有同事基于它开发 | merge | 如果用 rebase 改写历史后强制推送，会导致同事的本地分支与远程冲突，甚至丢失代码 |
| 大型团队的主分支（如 main、dev）合并 | merge | 主分支需要保留完整的合并记录，方便追溯“谁在什么时候合并了什么功能”，出问题时能快速定位 |
| 个人项目或短期临时功能分支 | rebase | 个人项目不需要复杂的历史追溯，用 rebase 保持提交记录简洁，后续维护更轻松 |
这次事故让我总结出几个“rebase 安全守则”，只要遵守这些规则，就能大幅降低风险：
绝对不在公共分支上用 rebase
公共分支（如 main、dev）是所有人协作的基础，一旦用 rebase 改写历史，会导致整个团队的分支混乱。如果需要同步公共分支的更新，用 merge 而非 rebase。
rebase 前先拉取远程最新代码
执行 rebase 前，一定要先通过 git fetch 获取目标分支的最新状态，避免基于旧版本做 rebase（这是我这次踩的核心坑）：
git fetch origin # 拉取远程所有分支的最新代码
git rebase origin/main # 基于远程main的最新版本做rebase，而非本地旧版本解决冲突时逐行检查，不盲目删除
rebase 冲突时，Git 会提示“哪些文件有冲突”，打开文件后，一定要仔细对比冲突部分的代码——尤其是同事的提交，确认无误后再保留，避免手滑删错代码。
rebase 出错时，立即用 --abort 回滚
如果在 rebase 过程中发现不对劲（比如冲突太多，或者误删了代码），只要还没执行 git rebase --continue，就能用以下命令彻底回滚到 rebase 前的状态：
git rebase --abort # 紧急回滚，救了我好几次推送前检查提交历史和差异
推送分支前，先用以下命令确认提交历史是否正确，代码差异是否符合预期：
git log --oneline --graph --decorate # 查看分支历史的图形化结构
git diff origin/feature # 对比本地feature分支和远程feature分支的差异经过这次事故，我对 merge 和 rebase 有了更通俗的理解：
merge 像是在账本上“追加记录”——不管之前的记录怎么分，新记录会明确写清“合并了哪部分内容”，不动旧账，安全可靠，但账本可能会有点乱；rebase 像是在“修改旧账本”——把之前的记录重新整理成整齐的顺序，账本变干净了，但如果改的时候不小心擦错了，旧记录可能就找不回来了。最后想分享一句心得：Git 是个很宽容的工具（很多操作都能回滚），但对“提交历史”的操作必须心存敬畏。代码丢失不可怕，可怕的是不知道为什么会丢。只有真正理解 merge 和 rebase 的底层逻辑，才能在团队协作中既保持高效，又避免给同事“挖坑”。
除非注明，否则均为李锋镝的博客原创文章，转载必须以链接形式标明本文链接
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。