上一篇傳送門：git 分支管理
在Git中，git merge和git rebase都是用來將一個分支的修改并入另一個分支，只不過方式不同。
在日常工作中基本都會有一個工作主分支，一般我們會新建一個新的分支開始我們的工作，以免影響主分支。我們假設以下的情景來說明代碼合并。
小李需要開發FeatureA，因此他在項目主分支的基礎上新建了一個FeatureA的分支開始了他的工作，在他工作的同時，同事修復了兩個bug，并且都合入了主分支，于是代碼分支變成 了下面這種情況：
這時候小李想基于修復好bug的版本繼續之前的開發，那么就需要將自己的代碼和已經分叉的主分支進行合并，采取的方法可以是
git merge,也可以是git rebase.
git merge
一般來說，最簡單的操作就是執行下面的步驟：
git checkout featureA
git merge master
或者直接：
git merge master featureA
這樣就會產生一個三路合并：
git merge的優點就是簡單，并且產生一個合并的歷史，但是如果master分支的歷史很活躍，你又想始終保持與master一致，那么多多少少那么多的合并歷史會影響到你分支歷史的整潔性。這時候git rebase就可以登場了。
關于更多git merge的詳細述說可以看我上一篇文章：git 分支管理
git rebase
作為merge的替代，我們可以這樣執行rebase：
git checkout featureA
git rebase master
它會把整個featureA的分支直接移到現在master分支的后面：
git rebase最大的特點就是會使你的項目歷史非常干凈，呈現出一條線性提交，因為它不會引入合并提交，這讓你更容易使用git log 、git bisect和gitk 來查看項目歷史。
不過說git rebase也是git中的黑魔法，如果不遵守使用git rebase的黃金法則，也會給你的項目歷史帶來災難性的影響，rebase使你的feature分支沒有合并提交歷史，所以你也看不出feature合并進了上游的哪些修改。
交互式的rebase
這里假設小A在他的featureA分支已經有三個提交了，這時候如果直接rebase就會把 這三個提交歷史都接到master分支后面。
而交互式的
rebase則可以對featureA的分支歷史進行清理。加上
-i,我們執行交互式的rebase:
git checkout featureA
git rebase -i master
它會打開你git的文本編輯器:
pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3
這個列表顯示了你fetureA的歷史，你可以通過更改順序，更改pick或者使用fixup來合并你的歷史。比如如果#2和#3包含了修復性的更改，你想合并他們，那么你可以加上一個fixup:
pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
fixup 5c67e61 Message for commit #3
如圖所示，
#2和#3被合并為一次提交，這樣在合并的過程中還能簡化項目歷史，這是git merge辦不到的。
Rebase黃金法則
當你使用Rebase更加方便地處理你的分支時，你也必須懂得有哪些潛在的風險。使用rebase的一條黃金法則就是，絕對不要在公共分支上使用它。假設你使用了，那么便會發生下面的情況：
如上圖，你在主分支上的
git rebase將master分支移到了featureA分支的后面，而其他開發者還是基于原有的master分支進行開發，這時候你的master分支就和別人的分叉了，如果需要同步，則需要額外的一次git merge,以讓你目前的master和別人的master合并，你的項目歷史更加令人迷惑。
所以，在進行git rebase時，務必確認有沒有別人在此分支上工作，如果有的話，那么你就得考慮一種無害的方式來進行你的提交，比如git revert這樣的操作。
