代码合并在日常开发中是较为常见的场景，采用合适的合并方式，可以起到事半功倍的效果。对应在 Git 中合并的方式主要有三个，Merge，Rebase，Cherry-Pick. 开始部分会首先介绍一下这三个命令，并录制了一些动画，用于演示三个命令的不同合并过程。之后会实操这三个命令，演示如何解决冲突。
Git MergeMerge 会将两个分支合并到一起，并生成一个新的 commit 记录。新生成的 commit 节点会有两个父节点。一般在开发某个新功能时，会选择新的分支，之后在合并回主线。
在 master 分支上，使用 git merge bugFix 将 bugFix 分支合并到 master 分支。
Git rebaserebase 也能合并分支，它会取出一系列 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 ：
