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