在团队软件开发过程中，代码合并是一个基本且频繁执行的任务。
Git 提供了多种合并代码的策略，其中最常用的是 merge 和 rebase。
尽管二者的终极目标是相同的——整合代码变更——它们的方法和推荐的使用场景却有所区别。本文将详细介绍和比较这两种策略。
一、基于 merge 的合并介绍
1.1 如何使用
情景 1：
当你的代码处在分支 branch-a，而本地有另外一个分支 branch-b 的时候，使用
git merge branch-b
可以将 branch-b 分支的代码，merge 到当前所处的 branch-a 分支上。
情景 2：
当你的代码处在分支 branch-a，直接使用 git pull origin branch-b 拉取仓库中 branch-b 分支的最新代码时，默认情况下，git pull 命令执行的是 fetch 后跟 merge。也即：
git pull origin branch-b
# 等价于
git fetch origin branch-b # 拉取远端 branch-b 的最新状态，此刻本地的 branch-b 依旧不是最新代码
git merge origin/branch-b # 合并远端 branch-b 最新代码，此刻本地的 branch-b 依旧不是最新代码
最新版本的 git 会在项目首次 pull 时，让你设置默认的合并行为；这里说的默认选用 merge 是老版本的 git。
要全局设置 git pull 使用 merge，可以配置
git config --global pull.rebase false
下图是一个更加复杂的示例，branch-a 签出 branch-b 和 branch-c，按照时间顺序（图中由下到上）发生了如下事情
branch-a签出branch-b和branch-cbranch-b提交了一次代码（节点b1）branch-c提交了一次代码（节点c1）branch-b提交了一次代码（节点b2）branch-c提交了一次代码（节点c2）branch-c被合并进了branch-a（图中这种情况不会发生任何冲突，因为branch-c签出、提交、合并过程中，branch-a并未发生代码改变）branch-b提交了一次代码（节点b3）branch-b被合并进了branch-a（此时有可能发生冲突，因为branch-b和branch-c可能修改同一个位置的代码）
1.2 合并方式
git merge 创建一个新的合并提交，它具有两个父提交，分别指向合并前两个分支的最新提交。
例如上面的例子中，branch-c 被合并进 branch-a 时
- 节点
a2就是新的合并提交 - 节点
a1和c2就是a2的两个父提交
1.3 历史记录呈现形式
使用 merge 时，历史记录保持了分支形式，从而可以清晰地展示各个分支的合并点与路径。
例如上面的例子中，合并后即便删掉 branch-b 和 branch-c，提交历史也会保留，即： b1、b2、b3、c1、c2
1.4 冲突处理方式
如果合并时遇到冲突，Git 会停止合并过程，让用户一次性解决冲突，然后创建一个新的合并提交来完成合并过程。
二、基于 rebase 的合并介绍
2.1 如何使用
情景 1
当你的代码处在分支 branch-a，而本地有另外一个分支 branch-b 的时候，使用
git rebase branch-b
可以将 branch-b 分支的代码，merge 到当前所处的 branch-a 分支上。
git rebase 命令用于将一个分支的更改重新应用到另一个分支上。在分支上执行 git rebase 时，Git 将更改从一个分支上提取出来，然后在基底分支的头部重新应用它们。
情景 2
要使 git pull 默认执行 rebase 而不是 merge，可以通过 git config --global pull.rebase true 命令进行设置。
关于 rebase 的示例，要比 merge 的复杂一些，让我们先考虑如下情况
branch-a签出branch-b和branch-cbranch-b提交了一次代码（节点b1）branch-c提交了一次代码（节点c1）branch-b提交了一次代码（节点b2）branch-c提交了一次代码（节点c2）
此时如果处于 branch-a 分支上，执行
git rebase branch-c
将得到如下的分支和提交结构
此时如果处于 branch-a 分支上，执行
git rebase branch-b
将得到如下的分支和提交结构
那么，为什么 branch-c 的操作早于 branch-b，但是整体操作完，b1 和 b2 位于 c1 和 c2 之前呢？
这是因为执行 git rebase branch-name 的时候，会找到当前分支和 branch-name 分支的共同祖先，然后把当前分支在最早公共祖先之后的提交，好像新的提交一样一个个提交到 branch-name 的最新代码之后。
在上面的例子中，branch-a 分支和 branch-b 的公共祖先是 a1，所以会以 branch-b 的最后一次提交（b2）作为基础，将 branch-a 在 a1 之后的提交（c1、c2）依次应用上去。
合并方式
rebase 通过提取分支上的更改，并将它们应用到目标分支的最新提交之后，从而使得项目历史线性化。
在上面的例子中我们可以看到，使用 rebase 合并得到的提交记录不像使用 merge 合并得到的提交记录一样交错在一起，不容易拆分。
历史记录呈现形式
使用 rebase 会产生一个线性的历史记录，好像所有更改都是顺序发生的，使得项目历史看起来像是单线程进行的。
冲突处理方式
rebase 过程中的冲突必须按照每个提交顺序单独解决。解决每个冲突后，需使用 git rebase --continue 来继续 rebase 过程。
三、二者对比
适用场景比较
- merge 适合于需要保持详细合并历史的公共分支，如主分支或发布分支。
- rebase 更适合于个人开发分支，在合并到公共分支之前，保持历史记录的整洁和线性。
| 比较维度 | merge | rebase |
|---|---|---|
| 合并方式 | 创建新的合并提交，有两个父提交 | 提取提交在目标分支最新提交后重新应用 |
| 历史记录呈现形式 | 分支式，能看到分支合并情况 | 线性，看上去像所有提交在一条直线上 |
| 冲突处理方式 | 一次性解决冲突后提交合并结果 | 逐个解决每个提交的冲突，使用 git rebase --continue 继续 |
| 适合的公共分支场景 | 多开发者频繁合并，要求完整历史记录 | 需要线性历史记录，对美观度有要求 |
| 适合的个人分支场景 | 无特殊要求，记录分支合并历史即可 | 保持历史整洁和线性，便于审查 |
在实际开发中，团队可能会结合使用 merge 和 rebase 策略来充分利用它们的优势，例如在个人分支上使用 rebase 保持历史整洁，最后在合并到公共分支时使用 merge。
