Merge，Rebase，Cherry-Pick 一文解惑

代码合并在日常开发中是较为常见的场景，采用合适的合并方式，可以起到事半功倍的效果。对应在 Git 中合并的方式主要有三个，Merge，Rebase，Cherry-Pick. 开始部分会首先介绍一下这三个命令，并录制了一些动画，用于演示三个命令的不同合并过程。之后会实操这三个命令，演示如何解决冲突。

Git Merge

Merge 会将两个分支合并到一起，并生成一个新的 commit 记录。新生成的 commit 节点会有两个父节点。一般在开发某个新功能时，会选择新的分支，之后在合并回主线。

在 master 分支上，使用 git merge bugFix 将 bugFix 分支合并到 master 分支。

Git rebase

rebase 也能合并分支，它会取出一系列 commit 记录，复制它们。然后在目标分支逐个放下去。rebase 的好处是能保持线性的提交历史，从而使历史更加清晰。

在 bugFix 分支上，使用 git rebase master 分支，会将 bugFix 分支上的 commit 记录复制到 master 分支，并且保证了提交历史是线性的。

rebase 除了可以在合并时使用，还可用于整理 commit 记录。

使用 rebase 来整理记录

使用 git rebase -i 命令打开交互式的 rebase UI. 在打开的界面中会显示每个 commit 的哈希值以及提交说明，可以在其中调整 commit 的顺序、删除不想要的提交、以及合并提交。

通过 git rebase -i HEAD~4 后，我们看到了实际的交互式界面，但实际界面一般由 vim 打开并进行相应的操作。在这里，我们删除 c2，调整了 c5 和 c4 的位置。

这里需要注意的是：在真实的环境中，打开后的交互页面，commit 记录方向和 log 记录的 commit 是相反的。

cherry-pick

cherry-pick 而是将一些 commit 复制到当前的分支的 HEAD 上，和 rebase 相比，更加灵活，可以随意的选择 commit 进行复制。

通过 git cherry-pick c3 c4 c7 将其他分支上的 3 个 commit 复制到当前的 master.

三种情况下的冲突解决

场景模拟：团队开发时，不同的开发者需要经常会对公共类进行修改。当修改的位置重合或者删除公共的代码片段后，便会产生冲突。现在模拟这一场景。

首先，创建一个仓库用于演示，其中包含一个名叫 origin.txt 的文件，并在其中写入 "line1"，在 master 分支提交。

git 仓库初始化：

mkdir merge-conflict-things
cd merge-conflict-things
git init
vim origin.txt
echo line1 > origin.txt

创建初始 commit 及三种情况 branch 用于演示：

git add .
git commit -m "add origin.txt"
git branch merge_branch
git branch rebase_branch
git branch cherrypick_branch

查看初始化提交信息

git log --oneline --all  -n4 --graph

准备工作：在 master 分支上，创建两个 commit.

第一个 commit : 对 origin.txt 增加一些内容，相当于增加一个 feature.

在 origin.txt 中添加 "line2" 后：

line1
line2

第二个 commit 用于对过去提交的内容进行修改，相当于 Bug Fix.

origin.txt 的内容如下：

line1 - fixed
line2

接下来，会在三个分支进行相同的操作，并演示如何解决冲突。

git merge

在 merge_branch 分支，模拟和 master 分支相同的操作，这里提交的过程就不演示了，只要和 master 分支提交的内容不同即可。

第一个 commit：用于增加 feature "line 2 in merge branch"。

第二个 commit：同于修改之前的 bug "line 1 fixed in merge branch"。

提交后的内容如下，merge 分支多了两个 commit ：

下面将 merge 和 master 分支进行合并，通常的规范是在次分支去主动合并主分支的代码，然后再推送给主分支，这样做是由于所有分支都是基于主分支，万一在主分支发生错误，影响较为广泛。

进行 merge 操作

git merge master

由于 master 和 merge 分支修改了相同的内容，这时 git 并不知道哪个是需要的，所以提示 origin.txt 发生冲突，让我们手动解决。

在 <<< HEAD 和 ===== 中间的内容是当前所在的分支的内容，下面的是 master 分支上的内容。

这里你需要注意的是，这里提示冲突的行是两个 commit 的内容。这就意味着，**merge 解决冲突时内容是基于两个分支的所有的 commit **

选择 merge_branch 的方案进行提交。

git add origin.txt
git commit -m "fixed conflict with master"

可以看到，merge 操作将分开的分支进行合并，并**形成一个新的 merge commit. **

git rebase

在 rebase_branch 分支上模拟 master 的提交操作。

第一个 commit 添加了新行：“line2 - rebase branch”

第二个 commit 用于修改bug： “line1 - rebase branch”

结果如下：

使用 rebase 合并操作

git rebase master

查看冲突的文件：

rebase 的合并过程不同于 merge，在合并时会选取 master 的所有 commit，和当前分支中一个出现冲突的 commit 进行合并。

如上图中所示，HEAD 指针停留于master 分支上最新的 commit 节点，而 rebase 指针指向添加 feature 的节点。

由于 rebase 和 merge 相比较为特殊，这里详细演示下，选取 master 分支内容，选取 rebase 分支内容 ，选择 master 和 rebase 分支的共同内容的处理方法。

1. 选择 rebase 分支内容作为合并后的结果

保存当前的修改：

git add origin.txt
git rebase --continue

修改后的内容直接就提交成功了，因为第二次需要合并的 commit 本就是基于当前内容的 commit，并不会产生冲突。

2. 选择 master 分支内容作为合并后的结果

保存当前的修改：

git add origin.txt
# 由于我们选择了 master 分支内容进行合并，而当前又基于 master，和 master 本身分支上的内容没有任何区别。
# 所以执行 skip 跳过这次冲突。 也就是意味着放弃当前分支提交的 commit，这个也能理解，既然要 master 的 commit，
# 当前分支的 commit 自然就不需要了，直接忽略掉，同时当前的 commit 也不会出现在 commit 的历史中。
git rebase --skip

接着会出现第二次冲突：

再次产生的冲突的原因是，之前解决冲突时，选择了 master 的内容，也就意味着在 rebase_branch 提交的 commit add feature for origin.txt in rebase 被放弃了，而当前的 commit fixed before commit in rebase_branch 是基于丢弃的那个 commit 。

了解到产生冲突的原因，任意选择内容，保存就可以了，这里我们选择了 rebase_merge 分支上的内容。

git add .
git rebase --continue

3. 选择将 master 和 rebase_branch 的内容合并后的结果

这里我们选择将 master 和 rebase_branch 的分支都保留下来：

保存当前的修改：

git add origin.txt
git rebase --continue

可以看到，第二次冲突产生，原因是 rebase_branch 分支中过去的 commit 出现变更，和 rebase_branch 原有 commit 的记录不一致。

同样的，我们也会遇到三种情况：

A 以第一次解决冲突后的内容为准：

git add .
# 这就意味着 rebase_branch 最新节点的添加的内容被舍弃，所以没有任何改变，可以直接跳过
git rebase --skip

B 以 rebase_branch 分支上的结果为准

C 保留 rebase_branch 和 之前修改后的内容：

B C 处理方法相同：

git add .
# 保存我们的更改就可以了
git rebase --continue

注意有时 git rebase --continute 操作无法生效时，原因在于 rebase 会逐一应用当前分支的 commit 到目标分支（一般是 master）。像例子中演示的那样，第一次解决冲突后的内容，和第二次解决冲突后的内容一样，这时用 git rebase --skip 跳过就好了。

git cheery-pick

在 cherrypick_branch 分支上模拟 master 的提交操作。

使用 cherry-pick 进行合并操作

git cherry-pick  eb1a8fb

出现了冲突，可以看到和 rebase 操作的合并操作刚好相反，这里是以 cherrypick_branch 的最新 commit 为准，去合并 master 的 commit.

选择 master 内容，进行合并：

git add origin.txt
git commit -m "fixed add feature conflict with master"

合并 master 分支上提交的第二个 commit：

git cherry-pick 23e106b

再次出现了冲突：

修改后，提交就可以了：

git add origin.txt
git commit -m "fixed add feature conflict with master"

注意有时 git commit 操作无法生效，提示你是否提交的一个空的 commit. 原因在于修改后的冲突内容和当前分支的原有内容一样。但这样有些矛盾，取过来别人的 commit，最后却不用。解决办法是，取消 cherry-pick 这个 commit 或者提交一个空的 commit 信息。

总结

git merge 是基于两个分支上的最新内容到有冲突的内容之间的所有 commit 进行合并，之后会形成一个新的 commit 记录，将两个分支重新关联起来。

git rebase 正如它的中文名字“变基操作”一样，会将所在分支新添加的内容，增加到目的分支，并保证了 commit 提交记录的串行性。简单来说就是，会以目的分支（一般是 master）为基础，逐一的将当前分支的 commit 记录应用。需要注意的是，在应用时并不是直接应用在 master 分支，而是将 master 分支整体拷贝，然后将当前 commit 应用在拷贝后的分支上。

git cherry-pick 和 rebase 操作正好相反，会以当前的分支为基础，然后将 commit 一个个的拿过来应用。形成的 commit 记录也是串行的。

最后附上一个 Git 练习网站，网站上设置了各种任务，可以用于检验自己的操作水平。