SourceTree版本控管(五) - 基本功能介紹 Merge / Rebase

• Merge

我們在先前新增了一個AudioPlayer branch並且開發了一些新功能，接下來將說明如何使用Merge把開發的新功能結合到master的commit上。




首先確認目前版本路線處在master branch，並且點擊Merge按鈕。

選擇要合併的branch之後按下OK。

從圖表可以看到，AudioPlayer的版本已經接回到master branch路線下了。

Unity專案也成功地將兩個branch個別開發的功能結合在一起。

通常在merge之後會因為meta檔案的變化而衍生新的狀態。

這時候只要將修復後的狀態再次commit一個新的版本即可。

我們可以依照這樣的特性將一個專案的多個功能個別獨立成不同的branch，等到某項功能完成後再merge回來，這樣的模式也很方便同時讓多位協同開發者獨立分工。

• Rebase

當兩個branch隨著時間各自有了不同版本的commit，我們可能會有這樣的需求:

branchB的新功能需要與branchA在分歧之後才開發出來的某個commit版本互相搭配才行。

最直接的方式就是merge兩個branch取得該特性之後，再個別開發新的功能。

雖然解決了取得其他branch中某個特性的需求，但是這邊的關係線就開始複雜了起來，如果常常使用這樣的作法我們會看到一堆錯綜複雜的線，反而很難分開彼此之間的關係，這時候我們可以使用rebase來替代頻繁使用merge造成的的複雜度。

下面直接用一個範例來做說明，這個repository共有兩個branch - master 與 other。

隨著專案的開發，master branch的版本已經擁有了master5.txt的功能。

而other branch是從add master2這個commit開始分歧出去的，所以僅支援到master2.txt的功能。

在other branch的開發線軸上，因為other2.txt 必須與 master5.txt結合才能繼續作用，因此我們將兩個branch做一次merge。

這時候other branch的commit已經擁有了mater5.txt的功能。

而master branch的commit則是維持原狀，一切都跟預期的一樣。

在merge之後兩個branch再各別獨立開發新功。因為兩個branch已經merge過一次，因此在開發過程中產生了一條交錯的關聯線，加上add master2的分歧線總共有兩條關聯線。

如果我們將檢視模式改成Ancestor Order則會呈現更複雜的架構。

接著我們來看看使用rebase的方式會有什麼差異，先把repository再次回復到merge之前的狀態，並且checkout到other branch。

對著master branch點選右鍵，並且選擇Rebase current changes onto master。

接著會出現一個詢問視窗，按下OK。

我們可以觀察到使用rebase作法之後branch的關聯線與先前merge的做法有一些差異。

接著兩個branch各自獨立開發出了新的功能，我們可以發現到兩個分歧的branch之間只有一條關聯線。

切換到Ancestor Order模式來檢視一樣是非常簡潔的。

兩個branch的commit版本內容與先前merge的做法結果也是一致的。

比較上面兩種做法我們可以發現，使用rebase的做法的確可以整個圖表的關係更加簡潔。那rebase究竟是什麼呢?

從下面兩張的圖表的比較我們可以觀察到，other branch本來是從add master2分歧出去的，現在變成從add master5分歧出去了。

由這樣的差異性我們可以這麼理解rebase的功能:

"將branch B的分歧點移動到branch A最後的commit版本，藉此取得branch A的新功能"

是不是突然懂了呢!?

了解merge與rebase這兩個功能的特性之後，我們可以依照不同的狀況選擇比較適合的方式來處理branch之間的憑依關係，在日後管理上也能更為清晰明瞭整個開發線軸的關係。

參考來源:

使用 git rebase 避免無謂的 merge

Rebase 合併分支

在下面的章節我們將介紹如何使用Push與Clone來實現多人開發的架構。

SourceTree版本控管(六) -  基本功能介紹 Push / Clone