【原创】Git 分支的合并【Learn Git Branching】
merge
git merge是我们要学习的合并工作的第一个方法。合并产生一个特殊的提交记录，它包含两个唯一父提交。有两个父提交的提交记录本质上是：“我想把这两个父提交本身及它们的父提交集合都包含进来。”
1. 有共同祖先，但非直接上下游关系的分支
根据C1、C2、C3这三个提交对象（C1是C2、C3的共同祖先），合并之后，生成了一个新的提交对象，包含了两个父提交。假如从合并后的master出发，开始沿着箭头向上游走，在到达起点的路上会经过所有的提交记录，这说明master包含了所有代码库的修改。
2. 直接上下游分支关系
可以看出，合并只是将bugFix分支移动到上游的master分支，使得bugFix和master指向同一提交对象。
分支合并情况有多种，一种是当前master分支所指向的提交对象为新建分支的直接祖先，一种则不是。
第一种情况的合并比较简单，合并时，只需要前移master指针使它指向新建分支所指向的commit对象。这种情况下，如果在master和新建分支之间还有多个直接祖先为master的分支，直接和最新的合并，那么如果再和上游的分支合并，会提示already up-to-date。如果合并的是上游的，那么可以一步一步合并到最新的分支。
第二种情况的合并比较复杂，因为当前master分支所指向的commit对象不是新建分支的直接祖先，Git不得不进行一些额外的处理，一般会取新建分支所指向的commit、master所指向的commit和新建分支和master的共同祖先所指向的commit这三个对象合并为一个新的commit对象，并生成结果的文件快照，该文件快照是一些合并时被修改的文件快照。
（2）Git会自动选取合适的新建分支和master的共同祖先作为合并基础，这一点和CVS和subversion的人工选择不同，极大的简化操作流程。
rebase
rebasing是在分支之间合并工作的第二种方法。Rebasing就是取出一系列的提交记录，"复制"它们，然后把在别的某个地方放下来。虽然听上去难以理解，rebasing 的优势是可以创造更线性的提交历史。假如只允许使用rebasing，代码库的提交日志/历史会更好看。
简单地说下上面的三张图片所演示的效果和作用。开始，master分支和bugFix分支中的修改是唯一独立的，现在想要把bugFix分支里的修改直接移动到master分支中。在bugFix分支中，使用git rebase master命令，复制bugFix的最新提交对象，然后把它放在master分支的最新提交对象的后面，得到了一个更加线性好看的提交记录，此时bugFix是master的上游，应注意原来被复制的提交对象仍在、不会消失；现在唯一的问题是master分支还没有更新。接下来切换到master分支，把它rebase到bugFix分支，git rebase bugFix，因为master是bugFix的直接下游，所以Git只把master分支的记录前移到bugFix上而已。
rebase时候，git做了些什么呢？
1. 先将master分支的代码checkout出来，作为工作目录
2. 然后将bugFix分支从master分支创建起的所有改变的补丁，依次打上。如果打补丁的过程没问题，rebase就搞定了
3. 如果打补丁的时候出现了问题，就会提示你处理冲突。处理好了，可以运行git rebase –continue继续直到完成
4. 如果你不想处理，你还是有两个选择，一个是放弃rebase过程（运行git rebase –abort），另一个是直接用test分支的取代当前分支的（git rebase –skip）。
最后补一下 有关rebase的知识：
1 #将当前分支切换到mywork 2 git checkout mywork 3 git rebase origin
这些命令会把你的"mywork"分支里的每个提交(commit)取消掉，并且把它们临时 保存为补丁(patch)(这些补丁放到".git/rebase"目录中),然后把"mywork"分支更新到最新的"origin"分支（即"mywork"分支引用移动到origin上），最后把保存的这些补丁应用到"mywork"分支上。当'mywork'分支更新之后，它会指向这些新创建的提交(commit),而那些老的提交会被丢弃。 如果运行垃圾收集命令(pruning garbage collection), 这些被丢弃的提交就会删除.
使用rebase和merge之后的区别：
