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之后的區別：
