Git Merge vs. Rebase 对比详解

在使用 Git 进行团队协作或分支管理时，git merge 和 git rebase 是两种最常用的将一个分支的修改整合到另一个分支的方法。它们都能达到相同的最终目标——将不同分支历史上的修改合并——但在实现方式、提交历史的呈现以及适用场景上有着显著的区别。理解这两者的不同是熟练掌握 Git 的关键。

核心对比：

Merge (合并)：保留所有分支的原始提交历史，通过产生一个新的合并提交来连接不同的历史。
Rebase (变基)：将一个分支上的所有提交“移动”到另一个分支的末端，从而形成一个线性的、没有合并提交的提交历史。

一、Git Merge (合并)

1.1 工作原理

git merge 将两个或多个分支的开发历史整合到一个新的提交中。它会找到两个分支最新的共同祖先，然后将这两个分支从共同祖先到各自最新的提交的所有修改整合到一个新的合并提交 (merge commit) 中。

1.2 提交历史

非线性历史：git merge 会保留所有分支的原始提交历史，包括每个分支上的每一次提交。当从一个特性分支合并回主分支时，会在主分支上创建一个新的合并提交，这个提交会有两个或更多的父提交。
可追溯性强：由于所有提交都保留，合并提交明确指示了何时何地进行了合并操作，因此历史是真实的、完整的。

1.3 示例场景

假设 master 分支和 feature 分支并行开发：

1
2
3

A --- B --- C (master)
       \
        D --- E (feature)

在 master 分支上执行 git merge feature：

1
2
3

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

F 就是那个新的合并提交。它包含了 C 和 E 的所有修改，它的父提交是 C 和 E。

1.4 优点

保留完整历史：分支的开发痕迹、合并点都清晰可见，更容易理解项目的演变过程。
操作安全简单：不会重写历史，合并失败可以轻易回滚到合并前的状态。
适用于团队协作：特别是对于公共分支（如 master、develop），普遍采用 merge，避免重写历史给其他团队成员带来困扰。

1.5 缺点

提交历史可能混乱：频繁的特性分支合并会导致大量的合并提交，提交图（commit graph）变得复杂，像“毛线团”，难以阅读。
额外的合并提交：每次合并都会产生一个新的提交，即使没有实际的代码冲突。

二、Git Rebase (变基)

2.1 工作原理

git rebase 的字面意思是“变基”，即将一个分支的“基础点”改变到另一个分支的最新提交上。它会找到两个分支最新的共同祖先，然后将当前分支上从共同祖先以来的所有提交，在目标分支的最新提交之后重新应用一遍。

在这个过程中，它并不是简单地移动提交，而是创建了新的提交。原有分支上的提交会被丢弃，取而代之的是新的、拥有相同修改内容但不同 SHA-1 值的提交。这就是“重写历史”。

2.2 提交历史

线性历史：git rebase 会“压平”分支历史，使其看起来像是在目标分支的最新提交之后，线性地进行开发。没有合并提交。
历史被重写：由于 rebase 会创建新的提交，如果这些提交已经被推送到远程仓库，并且被其他开发者拉取，那么重写历史会带来问题。

2.3 示例场景

仍然是上面的分支结构：

1
2
3

A --- B --- C (master)
       \
        D --- E (feature)

现在，在 feature 分支上执行 git rebase master：

Git 会找到 feature 和 master 的共同祖先 B。
将 feature 分支上在 B 之后的提交 (D, E) 暂时存储起来。
将 feature 分支的头部移动到 master 分支的最新提交 C 上。
然后，将之前存储的提交 (D, E) 在 C 之后依序重新应用。

1
2
3

A --- B --- C --- D' --- E' (feature)
            ^
        (master)

注意 D' 和 E' 是新的提交，它们的 SHA-1 值与 D 和 E 不同，但包含了相同的代码修改。

现在，如果 master 分支想要整合 feature 分支的修改，只需要在 master 上执行 git merge feature (或者更常见的 git pull --rebase，或者如果 master 没有新的提交，直接使用 git push):

1	A --- B --- C --- D' --- E' (master, feature)

这被称为快进合并 (Fast-Forward Merge)，因为 master 可以直接将指针移动到 feature 的最新提交，而无需创建新的合并提交。

2.4 优点

提交历史清晰、线性：提交图非常整洁，易于阅读和理解。
没有额外合并提交：减少了不必要的提交，使得 git log 输出更干净。
更易进行代码审查：由于提交是线性的，可以更容易地按顺序审查每个独立的修改。

2.5 缺点

重写历史：这是最主要和最危险的缺点。永远不要对已经推送到公共仓库的提交进行 rebase！ 因为这会改变这些提交的 SHA-1 值，导致其他开发者在 pull 时遇到严重冲突，甚至可能丢失代码。
冲突解决可能重复：如果在 rebase 过程中遇到冲突，你需要逐个解决每个重新应用的提交的冲突，可能需要多次解决相同的冲突。
操作复杂性和风险高：相比 merge，rebase 在处理冲突或回滚时更复杂，更容易出错。

三、Merge vs. Rebase 对比总结

特性	`git merge`	`git rebase`
工作方式	创建一个合并提交，将不同分支历史连接起来。	将当前分支的提交“移动”并重新应用到目标分支的末端。
提交历史	非线性，包含所有分支和合并提交。	线性，看起来像一条直线，没有合并提交。
提交对象	保留原有提交，生成新的合并提交。	重写历史，生成新的提交对象。
安全性	高，不会重写历史，可以随时回滚。	低，会重写历史，已推送的提交绝对不能 `rebase`。
易读性	易于追溯分支的实际开发轨迹和合并点。	提交历史简洁、整洁，易于阅读。
冲突解决	通常只需解决一次合并提交的冲突。	每一个重新应用的提交都可能需要解决冲突。
适用场景	公共分支（`master`, `develop`）的合并；需要保留完整历史。	个人特性分支的本地清理（在推送到远程前）；追求线性整洁历史。
核心思想	“我把我所做的事情整合到你的工作里。”	“把我的工作放在你的工作之后，模拟我一直在你的基础上工作。”

四、何时使用 Merge？何时使用 Rebase？

1. 优先使用 `git merge` 的场景

所有已经共享给其他开发者的公共分支：这是最严格的准则。一旦你的提交被推送到公共仓库，并且其他开发者可能已经拉取了这些提交，就绝对不要对这些提交进行 rebase。master、develop 分支的合并总是使用 merge。
需要保留完整的项目演进历史：如果团队认为合并提交以及分支的真实轨迹是项目重要的一部分，那么 merge 是更好的选择。
对 Git 操作不熟悉或追求安全性：merge 相对更安全，出现问题更容易解决。

2. 优先使用 `git rebase` 的场景

你的本地特性分支，且未推送到远程（或只推送到你一个人使用的远程分支）：这是 rebase 最常见的用例。当你在一个特性分支上工作了一段时间，而 master 分支已经有新的更新时，可以在将特性分支合并回 master 之前，先在 feature 分支上 git rebase master，将 master 最新的修改合并到 feature 中，再进行 git merge master (通常是 fast-forward)。
清理提交历史：在将特性分支推送到远程或合并到主分支之前，使用 git rebase -i (交互式 rebase) 可以 squash（压缩）多个提交、reword（修改提交信息）、fixup（合并提交但丢弃提交信息）甚至删除提交，从而形成一个干净、有意义的提交历史。
追求极度线性的提交历史：一些团队偏爱没有合并提交的线性历史，认为这样更易于回溯和查看。

3. 工作流建议

一个常见的 Git 工作流是：

从 master (或 develop) 分支创建特性分支 feature-xyz。
在 feature-xyz 上进行多次提交。
在推送到远程之前或合并回 master 之前，检查 master 是否有新的更新。如果有：
- 方法 A (使用 rebase 清理)：在 feature-xyz 上执行 git pull --rebase origin master (或者先 git fetch origin，然后 git rebase origin/master)，将 master 最新的修改同步到 feature-xyz 上，并保持 feature-xyz 的历史线性。解决冲突后，再将 feature-xyz 推送到远程。
- 方法 B (使用 merge 保留历史)：在 feature-xyz 上执行 git merge origin/master，将 master 最新的修改合并到 feature-xyz 中，并产生一个合并提交。
当 feature-xyz 完成开发并测试通过后：
- 切换回 master。
- 执行 git merge feature-xyz。如果之前已经 rebase 过了，此时通常会是快进合并；如果之前是 merge，则会产生一个新的合并提交。

重点理解：rebase 主要用于清理你自己的本地本地提交**，而 merge 用于整合已经存在的、被共享的提交历史。

五、冲突解决

无论 merge 还是 rebase，都可能遇到代码冲突。

merge 冲突：当你在 git merge 时遇到冲突，Git 会停下来，让你手动解决冲突。解决完冲突后，git add . 然后 git commit，完成合并提交。
rebase 冲突：rebase 可能会在每个重新应用的提交上都遇到冲突。当遇到冲突时，Git 也会停下来。你需要解决冲突，然后 git add .，接着最重要的是运行 git rebase --continue 来继续应用下一个提交。如果你想放弃整个 rebase 过程，可以运行 git rebase --abort。