到底用merge还是rebase?

大家工作日常用merge还是rebase呢？

今天用一个形象的 分支节点图 和 场景故事 来解释 merge 和 rebase 的区别，帮助你理解它们如何影响提交的历史的。

---

场景设定

假设你有一个主分支 main，初始提交为 A。你从 A 切出一个功能分支 feature，并做了两次提交 B 和 C。与此同时，主分支 main 也有其他人推送了新的提交 D 和 E。

初始状态：

B---C (feature)
     /
A---D---E (main)

你的目标是将 feature 分支的代码合并到 main 分支，但有两种不同的策略：merge 和 rebase。

---

1. 使用 merge 合并

执行命令：

git checkout main
git merge feature

合并后的历史：

B---C (feature)
     /     \
A---D---E---F (main)

• 特点：
• 生成一个新的 **合并提交 F**，明确记录分支交汇点。
• feature 分支的原始提交 B 和 C 被保留，历史完整。
• main 分支的历史是 非线性的，能看到分支的分叉和合并。

• 适用场景：
• 公共分支协作（如团队开发）。
• 需要保留完整的分支合并记录。

---

2. 使用 rebase 合并

执行命令：

git checkout feature
git rebase main   # 将 feature 的 B 和 C 变基到 main 的 E 之后
git checkout main
git merge feature  # 此时是快进合并（fast-forward）

合并后的历史：

A---D---E---B'---C' (main, feature)

• 特点：
• feature 的提交 B 和 C 被 复制 为新的提交 B' 和 C'（哈希值改变）。
• main 分支的历史是 完全线性的，没有分叉。
• 原始提交 B 和 C 被丢弃（如果分支已推送，需要强制推送 git push --force）。

• 适用场景：
• 个人分支整理（未推送的提交）。
• 希望提交历史保持整洁线性。

---

关键区别对比

操作	历史结构	提交哈希值	协作风险	适用阶段
merge	非线性（有分叉）	保留原始哈希值	无风险	公共分支合并
rebase	线性	生成新的哈希值	已推送时需强制推送	本地分支整理

---

形象的比喻

• merge 像搭桥：
在两条分支之间建一座桥（合并提交 F），保留两条分支的原始路径。所有人都能清晰看到从哪里分叉、在哪里合并。

• rebase 像时光机：
把 feature 分支的修改“时间旅行”到 main 分支的最新状态，假装你的工作一直基于最新的代码，但篡改了历史（原始提交消失）。

---

实际协作中的问题

如果 feature 分支已推送到远程仓库：

1. **用 merge**：其他人能看到一致的历史，直接 git pull 即可同步。

2. **用 rebase**：你需要 git push --force，而其他开发者如果之前拉取过旧 feature 分支，他们的本地历史会与远程冲突，必须手动修复。

---

通过上面的对比，我认为rebase在团队合作中会存在一些风险，merge 更安全的核心原因是不修改历史，而 rebase 的风险来自历史重写。