如何克服解決Git衝突的恐懼症？（Git基礎篇--下）

在上一篇中，介紹了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分支的管理相關內容，敬請期待～

微信公衆號： 碼上論劍 請關注個人我的技術微信公衆號，訂閱更多內容