Shell / Bash大前端
Git Merge vs Rebase 底层逻辑、适用场景与操作指南
深入解析 Git Merge 与 Rebase 的底层逻辑与核心差异。Merge 保留完整历史分叉，适用于公共分支合并，确保协作安全；Rebase 重写历史使其线性化，适用于本地私有分支整理与同步。文章强调了核心红线：严禁对已推送的公共分支执行 Rebase 操作。提供了企业级分支管理、冲突处理及代码评审的最佳实践规范，帮助开发者根据场景选择合适的工具，避免常见误区。
深入解析 Git Merge 与 Rebase 的底层逻辑与核心差异。Merge 保留完整历史分叉，适用于公共分支合并，确保协作安全；Rebase 重写历史使其线性化，适用于本地私有分支整理与同步。文章强调了核心红线：严禁对已推送的公共分支执行 Rebase 操作。提供了企业级分支管理、冲突处理及代码评审的最佳实践规范，帮助开发者根据场景选择合适的工具，避免常见误区。
几乎每个开发者每天都在和 Git 打交道，但分支合并时的核心问题——'到底用 Merge 还是 Rebase？'，却难倒了无数人。有人无脑用 Merge，导致仓库提交历史分叉成'蜘蛛网'；有人盲目跟风用 Rebase，结果重写了公共分支历史，把整个团队的协作流程搞崩。这两个命令的核心区别到底是什么？什么时候该用哪个？本文将从 Git 底层对象模型出发，讲透 Merge 和 Rebase 的本质，搭配实战示例，明确区分易混淆点，给出企业级可落地的最佳实践。
要彻底搞懂 Merge 和 Rebase，必须先理解 Git 的核心设计——Git 是一个基于快照的分布式版本控制系统，分支本质是指向提交对象的可变指针。所有的合并操作，本质都是对提交对象和分支指针的操作。
Git 中的每一次提交（commit），都是一个不可变的快照对象，包含 4 个核心信息，所有内容共同生成唯一的 SHA-1 哈希值：
这里的核心关键点：只要提交的 parent、内容、元数据有任何一点变化，生成的 SHA-1 哈希值就会完全改变，变成一个全新的提交对象。这是理解 Merge 和 Rebase 核心区别的关键。
Git 的分支，本质上只是一个指向某个提交对象的、轻量级的可变指针。你创建一个新分支，本质只是创建了一个新的指针文件，里面存储了目标提交的哈希值，几乎没有任何性能开销。
而 HEAD 指针，本质是一个指向当前所在分支的指针，你切换分支，本质只是改变了 HEAD 的指向，然后把工作区更新为对应分支指向的提交快照。
这个底层逻辑，是所有 Git 操作的基础，接下来的 Merge 和 Rebase，都是基于这个核心逻辑实现的。
Git Merge 的官方定义是：将两个或多个开发历史合并在一起。它的核心设计目标是：在不修改现有提交历史的前提下，完成两个分支的合并，完整保留所有开发轨迹。
根据两个分支的提交状态，Git Merge 会自动选择两种合并模式：Fast-Forward（快进合并）和 Three-Way Merge（三方合并）。
当你要合并的两个分支，满足一个前提：目标分支（比如 main）在你创建特性分支之后，没有任何新的提交。此时两个分支的提交历史是线性的，Git 不需要生成新的合并提交，只需要把目标分支的指针，直接移动到特性分支的最新提交上，就完成了合并，这就是快进合并。
# 初始化 Git 仓库并配置用户信息
git init merge-rebase-demo
cd merge-rebase-demo
git config user.name "Demo User"
git config user.email "[email protected]"
# 主干分支初始提交（LCA 共同祖先）
echo "# Merge vs Rebase Demo" > README.md
git add README.md
git commit -m "chore: init project"
# 创建并切换到特性分支 feature/docs
git checkout -b feature/docs
# 特性分支提交新内容
echo "## Quick Start" >> README.md
git add README.md
git commit -m "docs: add quick start guide"
# 切回主干分支 main，此时 main 无新提交
git checkout main
# 执行快进合并
git merge feature/docs
合并完成后，执行 git log --oneline --graph 查看提交历史，输出如下：
* 45f8d21 (HEAD -> main, feature/docs) docs: add quick start guide
* a7c3d90 chore: init project
可以看到，main 分支的指针直接移动到了 feature/docs 分支的最新提交，没有生成任何新的合并提交，提交历史完全线性。
这是 Merge 最常用的场景，当两个分支满足：目标分支和特性分支，在分出之后都有了新的提交，此时两个分支的历史出现了分叉，无法执行快进合并，Git 会自动执行三方合并。
三方合并的核心逻辑，是 Git 会自动找到 3 个关键提交节点：
基于这 3 个节点，Git 会对比两个分支相对于共同祖先的差异，自动合并差异内容，最终生成一个全新的合并提交（Merge Commit）。这个合并提交有一个特殊的结构：它有两个 parent 指针，分别指向两个待合并分支的最新提交，以此完整保留两个分支的开发历史。
执行以下命令可完整复现三方合并场景：
# 基于上面的仓库，重置 main 分支到初始提交
git reset --hard a7c3d90
# 删除旧的特性分支
git branch -D feature/docs
# 重新创建特性分支
git checkout -b feature/login
# 特性分支第一次提交
mkdir src
echo "// user login core logic" > src/login.js
git add src/login.js
git commit -m "feat: add login core logic"
# 特性分支第二次提交
echo "// login input validation" >> src/login.js
git add src/login.js
git commit -m "feat: add login validation"
# 切回 main 分支，提交新内容，制造分叉
git checkout main
echo "// project base config" > config.js
git add config.js
git commit -m "chore: add base config"
# 执行三方合并
git merge feature/login
如果没有冲突，Git 会自动生成合并提交，并打开编辑器让你填写合并提交信息，默认信息为 Merge branch 'feature/login'。合并完成后，执行 git log --oneline --graph 查看历史，输出如下：
* 3f7e2d1 (HEAD -> main) Merge branch 'feature/login'
|
| * 2c8d3f4 (feature/login) feat: add login validation
| * 7d9e4f5 feat: add login core logic
* | 5a6b7c8 chore: add base config
|
* a7c3d90 chore: init project
可以清晰看到，提交历史出现了分叉，合并提交有两个父节点，完整保留了两个分支的所有开发轨迹。
--no-ff：强制关闭快进合并，即使可以快进，也强制生成合并提交。这是企业级团队最常用的参数，能完整保留特性分支的开发轨迹，方便后续回滚和追溯，示例：git merge --no-ff feature/login--squash：压缩合并，将特性分支的所有提交压缩成一个新的提交，合并到目标分支，不会保留特性分支的提交历史，也不会生成双父节点的合并提交，适合清理临时分支的零散提交--abort：合并出现冲突时，终止合并操作，恢复到合并前的状态Git Rebase 的官方定义是：在另一个基础提交的顶端，重新应用一系列提交。它的核心设计目标是：重新设置分支的基准节点，将分叉的提交历史线性化，保持提交历史的整洁可读。
很多人对 Rebase 的理解停留在'让提交历史变直'，但没有搞懂它的底层操作，这也是绝大多数坑的根源。
Rebase 的核心逻辑，拆解为 5 个不可拆分的步骤：
所有补丁应用完成后，变基操作结束，当前分支的提交历史变成完全线性的结构。
这里的核心关键点，也是和 Merge 最本质的区别：Rebase 会重写提交历史，LCA 之后的所有原始提交都会被废弃，生成全新的提交，即使内容完全不变，提交的哈希值也会完全改变，因为新提交的父节点、元数据都发生了变化。
我们用和上面三方合并完全相同的仓库场景，来演示 Rebase 的操作，让你直观看到和 Merge 的区别：
# 基于之前的仓库，重置 main 分支到初始提交
git reset --hard a7c3d90
# 删除旧的特性分支
git branch -D feature/login
# 重新创建特性分支，和 Merge 示例完全一致的提交
git checkout -b feature/login
mkdir src
echo "// user login core logic" > src/login.js
git add src/login.js
git commit -m "feat: add login core logic"
echo "// login input validation" >> src/login.js
git add src/login.js
git commit -m "feat: add login validation"
# 切回 main 分支，提交新内容，制造完全一致的分叉
git checkout main
echo "// project base config" > config.js
git add config.js
git commit -m "chore: add base config"
# 切回特性分支，执行 Rebase 操作，目标基准是 main 分支
git checkout feature/login
git rebase main
如果没有冲突，Rebase 会自动完成所有补丁的应用，执行完成后，执行 git log --oneline --graph 查看特性分支的提交历史，输出如下：
* 8d9e0f1 (HEAD -> feature/login) feat: add login validation
* 7c6d5b4 feat: add login core logic
* 5a6b7c8 (main) chore: add base config
* a7c3d90 chore: init project
可以看到，特性分支的提交历史变成了完全线性的结构，没有任何分叉，原本的两个提交，现在生成了两个全新的提交，哈希值和之前完全不同，它们的父节点变成了 main 分支的最新提交，相当于把特性分支的开发，'嫁接'到了 main 分支的最新提交之后。
此时，我们只需要切回 main 分支，执行快进合并，就能把特性分支的内容合并进来，不会生成任何合并提交，main 分支的历史也会保持完全线性：
git checkout main
git merge feature/login
合并完成后，main 分支的提交历史如下：
* 8d9e0f1 (HEAD -> main, feature/login) feat: add login validation
* 7c6d5b4 feat: add login core logic
* 5a6b7c8 chore: add base config
* a7c3d90 chore: init project
Rebase 在逐个应用补丁的过程中，如果遇到冲突，会暂停当前的变基操作，提示冲突文件，此时你需要遵循以下正确步骤处理，90% 的开发者在这里都会操作错误：
git add <冲突文件>，将修改后的文件加入暂存区git rebase --continue，继续应用下一个补丁，绝对不要执行 git commitgit rebase --abort这里必须强调：Rebase 的冲突是逐个提交处理的，如果你的特性分支有 10 个提交，可能需要解决 10 次冲突，这是 Rebase 的一个缺点；而 Merge 只需要解决一次冲突。
交互式变基是 Git 提供的超强功能，也是企业级开发中最常用的 Rebase 场景，它可以让你在变基的过程中，修改、合并、删除、重新排序提交，彻底整理你的本地提交历史。
它的基础用法是：git rebase -i <目标提交>，其中目标提交是你要整理的提交范围的父提交，比如 git rebase -i HEAD~3，就是整理最近 3 个提交。
执行命令后，Git 会打开编辑器，列出你要整理的所有提交，每个提交前面有一个操作命令，默认是 pick，你可以修改命令来实现不同的操作，核心命令如下：
| 命令 | 缩写 | 功能说明 |
|---|---|---|
| pick | p | 保留该提交，不做任何修改 |
| reword | r | 保留提交内容，修改提交信息 |
| edit | e | 保留提交内容，暂停变基，允许你修改提交的内容 |
| squash | s | 将该提交合并到上一个提交中，保留两个提交的信息 |
| fixup | f | 将该提交合并到上一个提交中，丢弃该提交的信息 |
| drop | d | 删除该提交，彻底丢弃该提交的内容 |
实战示例：合并最近 2 个零散的提交，整理成一个完整的功能提交
# 基于上面的 feature/login 分支，执行交互式变基
git checkout feature/login
git rebase -i HEAD~2
执行后，编辑器会打开如下内容：
pick 7c6d5b4 feat: add login core logic
pick 8d9e0f1 feat: add login validation
# 命令说明...
我们将第二个提交的命令改为 squash，修改后如下：
pick 7c6d5b4 feat: add login core logic
squash 8d9e0f1 feat: add login validation
保存退出后，Git 会打开新的编辑器，让你填写合并后的提交信息，修改为 feat: complete user login function with validation，保存后完成变基。
执行 git log --oneline 查看，原本的 2 个提交已经合并成了 1 个完整的提交，提交历史更加整洁。
我们用一张表格，从核心维度，彻底区分 Merge 和 Rebase 的区别，所有内容均基于 Git 官方定义，100% 准确：
| 对比维度 | Git Merge | Git Rebase |
|---|---|---|
| 提交历史修改 | 绝对不修改现有提交，仅新增合并提交，历史 100% 可追溯 | 重写现有提交，生成全新的提交哈希，原始提交会被废弃 |
| 提交结构 | 保留分支分叉历史，合并后会出现分叉结构 | 彻底消除分叉，合并后提交历史完全线性 |
| 冲突处理 | 仅需在生成合并提交时，一次性解决所有冲突 | 逐个应用补丁时处理冲突，有 N 个提交可能需要解决 N 次冲突 |
| 协作安全性 | 极高，不会修改公共历史，不会影响其他协作者 | 极低，对公共分支执行会彻底破坏团队协作历史，引发灾难性后果 |
| 可追溯性 | 极强，合并提交的双父节点完整保留所有开发轨迹，可精准追溯每个分支的合并过程 | 较弱，原始分支的开发轨迹被抹除，无法追溯提交的原始分支来源 |
| 回滚操作 | 简单，合并提交可直接通过 git revert -m 1 <hash> 一键回滚整个特性分支的修改 | 复杂，线性历史中无法直接区分特性分支的提交范围，回滚需要逐个处理提交 |
| 学习门槛 | 低，逻辑简单，不易出错 | 高，需要理解底层逻辑，操作不当极易引发问题 |
| 核心优势 | 安全、完整、可追溯，冲突处理简单 | 历史整洁、线性可读，可灵活整理本地提交 |
这是本文最核心的部分，也是 90% 的开发者踩坑的根源。Merge 和 Rebase 没有绝对的优劣，只有是否适合场景，用对了事半功倍，用错了灾难连连。
永远不要对已经推送到公共远程仓库、且有其他协作者基于其开发的提交，执行 Rebase 操作！
这是 Git 官方文档中明确标注的最高优先级警告，没有任何例外。
原因非常简单：你对公共分支执行 Rebase 后，重写了提交历史，远程仓库的提交哈希发生了变化，而其他协作者的本地仓库，还是基于旧的提交历史开发的。当他们执行 pull 操作时，Git 会把两个不同的历史合并，生成大量重复的提交，最终导致整个仓库的提交历史彻底混乱，甚至丢失代码。
即使你用 git push --force 强制覆盖了远程分支，也无法解决这个问题，只会让灾难扩散。唯一的补救方式，是让所有协作者都删除本地的对应分支，重新拉取远程的新分支，这在多人协作的团队中，成本极高，极易引发代码丢失。
满足以下任意一个场景，优先选择 Merge，绝对不要用 Rebase：
--no-ff 参数）可以完整保留特性分支的开发历史，保证主干分支的历史可追溯，回滚方便，且不会修改任何现有提交，绝对安全。满足以下所有前提条件，才可以使用 Rebase，缺一不可：
满足前提的情况下，以下场景是 Rebase 的最佳实践：
git rebase main，可以把你的特性分支'嫁接'到主干的最新提交上，保持提交历史线性，避免生成无意义的合并提交。git rebase -i 整理这些提交，合并零散提交、修改提交信息、删除无用提交，让每个提交都是原子性的、有明确意义的，方便代码评审。这里整理了开发者最容易踩的 10 个误区，100% 纠正错误认知，避免踩坑：
纠正：Rebase 不会丢失任何提交内容，它只是把原始提交废弃，生成了全新的提交，所有的代码修改都会完整保留，只是提交的哈希值和父节点变了，历史变成了线性的。Merge 保留的是分叉的原始历史，Rebase 保留的是线性的修改历史，两者都不会丢失代码内容。
纠正：Merge 和 Rebase 只是两个不同的工具，有不同的适用场景，没有高低优劣之分。用对了场景，两个都是专业的操作；用错了场景，哪怕是 Rebase，也是灾难性的错误。很多资深开发者，在公共分支合并时，永远只用 Merge，因为安全永远是第一位的。
纠正：两者的最终提交历史看起来都是线性的，但底层逻辑完全不同。Fast-Forward 合并只是移动了分支指针，没有修改任何提交，所有提交的哈希值完全不变；而 Rebase 是生成了全新的提交，哈希值完全改变，原始提交被废弃。
纠正：对公共分支执行 Rebase 后，哪怕用 git push --force 强制覆盖了远程分支，也无法解决根本问题。其他协作者的本地分支还是基于旧的历史，他们 pull 的时候会生成大量重复提交，导致历史彻底混乱。唯一正确的做法，是永远不要对公共分支执行 Rebase。如果非要修改已经推送的公共分支提交，必须用 git revert 生成反向提交，而不是 Rebase。
纠正：git pull 的默认行为是 git fetch + git merge，也就是先拉取远程分支的最新内容，然后用 Merge 合并到本地分支。如果你想让 pull 的时候默认用 Rebase，可以执行配置命令：git config --global pull.rebase true，这也是很多团队的推荐配置，可以避免本地分支生成大量无意义的合并提交。
纠正：git merge --squash 是将特性分支的所有提交压缩成一个新的提交，合并到目标分支，不会保留特性分支的提交历史，也不会生成双父节点的合并提交；而 Rebase 的 fixup 是在变基的过程中，将提交合并到上一个提交，是在同一个分支内整理提交历史，两者的使用场景和底层逻辑完全不同。
纠正：Rebase 之后，原始提交只是没有被分支指针指向了，并没有被立即删除。Git 有 reflog 机制，会记录所有分支指针的变化，你可以通过 git reflog 找到原始提交的哈希值，在 30 天内（Git 默认的过期时间）都可以恢复。
纠正：Merge 冲突解决完成后，需要执行 git commit 生成合并提交；而 Rebase 冲突解决完成后，需要执行 git add，然后 git rebase --continue，绝对不能执行 git commit，否则会生成额外的提交，导致变基失败。
纠正：绝对不能。Rebase 只能处理私有分支的历史整理和同步，无法替代 Merge 在公共分支合并中的作用。任何团队，都不可能只用 Rebase 不用 Merge，否则协作一定会出问题。
纠正：Git 的三方合并，是基于共同祖先的差异合并，不是简单的覆盖。Git 会对比两个分支相对于共同祖先的修改，只要两个分支修改的不是同一行代码，Git 会自动合并；只有修改了同一行代码，才会提示冲突。这也是 Git 合并能力强大的核心原因。
基于 Git 官方推荐，结合业界主流的 Git Flow、GitHub Flow、GitLab Flow 规范，我们整理了一套可直接落地的、零坑的合并策略最佳实践，无论是小团队还是大型企业，都可以直接使用：
| 分支类型 | 分支命名 | 核心用途 | 合并策略 | 禁止操作 |
|---|---|---|---|---|
| 主干分支 | main/master | 存放可部署的生产代码，永远保持稳定 | 仅接受 PR/MR 合并，必须使用 git merge --no-ff，禁止直接提交 | 禁止 Rebase、禁止强制推送、禁止直接提交 |
| 特性分支 | feature/* | 开发者本地开发新功能 | 开发过程中用 git rebase main 同步主干代码，用 git rebase -i 整理提交历史；合并回主干用 Merge --no-ff | 禁止 Rebase 已经推送到远程的共享特性分支 |
| 发布分支 | release/* | 版本发布前的测试、预发布 | 用 Merge 合并特性分支，修复 bug 直接提交 | 禁止 Rebase、禁止强制推送 |
| 热修复分支 | hotfix/* | 生产环境紧急 bug 修复 | 开发完成后，用 Merge 同时合并回 main 分支和 release 分支 | 禁止 Rebase、禁止强制推送 |
git push --force，仅允许对自己的私有特性分支，使用 git push --force-with-lease 强制推送，--force-with-lease 会检查远程分支是否有新的提交，避免覆盖其他人的修改，比--force 安全得多git pull --rebase，或者配置全局默认 pull 用 rebase，避免本地分支生成大量无意义的合并提交git rebase --abort 放弃变基，改用 Merge 合并git merge --no-ff，禁止快进合并，确保完整保留特性分支的开发轨迹回到最开始的灵魂拷问：到底用 Merge 还是 Rebase？
答案非常简单，记住两句话就够了： 公共分支合并用 Merge，安全完整可追溯；私有分支整理用 Rebase，干净线性易阅读。
Git Merge 和 Rebase，不是对立的两个选项，而是互补的两个工具。Merge 的核心价值是安全和可追溯，是团队协作的基础保障；Rebase 的核心价值是整洁和灵活，是本地开发的效率工具。
你不需要盲目跟风用 Rebase，也不用无脑只用 Merge，只要理解了它们的底层逻辑，守住了公共分支不用 Rebase 的核心红线，根据场景选择合适的工具，就能把 Git 用得得心应手，再也不会因为合并操作踩坑。
最后，再强调一遍 Git 官方的最高警告：永远不要重写已经公开的提交历史！
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online
将 HTML 片段转为 GitHub Flavored Markdown，支持标题、列表、链接、代码块与表格等；浏览器内处理，可链接预填。 在线工具，HTML转Markdown在线工具，online
通过删除不必要的空白来缩小和压缩JSON。 在线工具，JSON 压缩在线工具，online
将JSON字符串修饰为友好的可读格式。 在线工具，JSON美化和格式化在线工具，online