13.Git分支-變基（rebase）、rebase VS merge

1.變基的基本操做

　　在Git中整合來自不一樣分支的修改主要有兩種方法：merge和rebase。

看下面的例子： 開發任務分叉到了兩個不一樣的分支，而且都有了新的提交。

這時候咱們能夠使用 git merge 命令將experiment分支合併進入master分支，Git會將C三、C4以及二者最近的共同祖先作一個三方合併，而且生成一個新的提交。以下圖所示：

　　其實咱們還能夠使用rebase命令：rebase命令將提交到某一分支上的提交都移至另外一個分支上

$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command

　　以下圖所示：  使用rebase以後，將experiment分支上的提交移動到了master分支的後面。

　　原理：首先找到兩個分支（當前所在分支experiment和目標基底分支master）的最近共同祖先（即C2），而後對比當期分支相對於最近共同祖先的全部提交，提取相應的修改存爲臨時文件，而後將當前分支指向目標基底（即C3），最後將此前存好的臨時文件依次應用（理解爲將從當前分支上，從最近共同祖先開始的後一個提交節點，開始複製，放到目標基底後）。

　　完成rebase操做以後，能夠運行如下命令，進行一次快速移動。

$ git checkout master
$ git merge experiment

　　操做完成以後，提交歷史以下圖所示。

　　與直接使用merge命令相比，rebase命令能夠使提交歷史更加的整潔，看上去就像是一條直線。使用rebase的目的是是提交歷史看起來更加的整潔，其實，不管是經過merge仍是rebase，整合的最終結果都是同樣的，只不過rebase的提交歷史看起來更加的整潔。rebase是將一系列提交按照原有次序依次應用到另外一分支上，而merge是將最終結果merge在一塊兒。

2.rebase VS merge 

　　對於rebase和merge哪一種好，有兩種觀點：

　　1.有一種觀點認爲，倉庫的提交歷史便是記錄着實際上發生過什麼，它是一種歷史文檔，自己具備價值，不能隨意修改，這些歷史應該被保留下來，供後人進行查閱。這種觀點支持使用merge而不是rebase。

　　2.另外一種觀點正好相反，他們認爲提交歷史是項目開發過程當中發生的事情，沒有人會出版一本書的初版草稿，都是須要進行屢次修訂以後才能進行出版的，修訂以前的這些歷史不該該被讀者看到。這種觀點鼓勵使用rebase。

　　總的原則：只對還沒有推送或分享給他人的本地修改執行rebase操做清理歷史，從不對已經提交到別處的提交進行rebase操做。