在上一篇中，介紹了git的初始化配置配置、獲取幫助、初始化倉庫、跟蹤新檔案、提交、忽略某些檔案，以及分支，具體文章：如何克服解決Git衝突的恐懼症？（Git基礎篇--上），本篇將介紹分支合併相關的git merge與git rebase。
merge
分支合併的方法一就是git merge，通過圖示更容易理解：
執行命令如下：
git merge bugFix
git checkout bugFix
git merge master
複製程式碼執行過程如下：
rebase
分支合併的方法二就是git rebase，通過圖示更容易理解：
執行命令如下：
git rebase master
//下面兩步只是示例，不建議使用
git checkout master
git rebase bugFix
複製程式碼執行過程如下：
merge與rebase的對比
Merge好在它是一個安全的操作。現有的分支不會被更改，避免了rebase潛在的缺點，另一方面，這同樣意味著每次合併上游更改時feature分支都會引入一個外來的合併提交。如果master非常活躍的話，這或多或少會汙染你的分支歷史。雖然高階的git log選項可以減輕這個問題，但對於開發者來說，還是會增加理解專案歷史的難度。
Rebase最大的好處是你的專案歷史會非常整潔。首先，它不像git merge 那樣引入不必要的合併提交。其次，rebase導致最後的專案歷史呈現出完美的線性——你可以從專案終點到起點瀏覽而不需要任何的Fork。這讓你更容易使用git log、git bisect和gitk來檢視專案歷史。
不過，這種簡單的提交歷史會帶來兩個後果：安全性和可跟蹤性。如果你違反了Rebase黃金法則，重寫專案歷史可能會給你的協作工作流帶來災難性的影響。此外，rebase不會有合併提交中附帶的資訊——你看不到feature分支中併入了上游的哪些更改。
rebase黃金法則
當你理解rebase是什麼的時候，最重要的就是什麼時候不能用rebase。git rebase的黃金法則便是，絕不要在公共的分支上使用它。
rebase衝突解決
假設有兩個分支，master與bugFix：
master分支的README.md檔案內容如下：
史培培
複製程式碼bugFix分支的README.md檔案內容如下：
碼上論劍
歡迎關注我的公眾號
http://hellomypastor.net
複製程式碼在bugFix分支執行如下命令：
git pull --rebase
複製程式碼發現衝突：
<<<<<<< HEAD
史培培
=======
碼上論劍
歡迎關注我的公眾號
http://hellomypastor.net
>>>>>>> init
複製程式碼解決衝突之後，執行：
git add README.md
git rebase --continue
複製程式碼這樣就解決衝突了，是不是很簡單？
建議
用pull --rebase，而不用pull（預設merge），這樣的話在pull的時候就自行在本地解決兩路衝突，而不是merge的時候麻煩的多路merge，這才是git的正確使用方式。
相信大家對git的基礎已經基本掌握，不妨在自己的git環境中動手試一試，下篇將講述《Git分支管理策略》，主要介紹git分支的管理相關內容，敬請期待～
