團隊的 GIT 分支管理策略 (1) ：基本概念

fin

此文分兩個重點部分：『整合』：工程師們如何把自己的產出整合成一個統一版本。『準備發佈』：從整合好的 codebase 到實際上線的分支處理。

Patterns for Managing Source Code Branches 系列：

團隊的 GIT 分支管理策略 (1) ：基本概念（本篇）
團隊的 GIT 分支管理策略 (2) ：主線整合與功能分支
 團隊的 GIT 分支管理策略 (3) ：持續整合以及相關比較
 團隊的 GIT 分支管理策略 (4) ：發佈的分支模式
 團隊的 GIT 分支管理策略 (5) ：其他分支模式

GIT 是現在主流的開發版控工具，其分支功能帶給團隊同時開發但又不互相影響的可能，但最終這些分支還是要整合在一起，而這常常是痛苦的來源。此文摘要 Martin Fowler 的 Patterns for Managing Source Code Branches，主題是探討各種分支策略的優缺點，並以此思考哪種策略比較適合自己的團隊。

註一：原文講的是分支策略，其實不僅只有指 GIT，但我們最常碰的就是 GIT 所以這裡以 GIT 做標題
註二：雖然 GIT 號稱分散式版控，但實際上程式碼最終還是只有一個統一版本，顧不管怎麼樣開發，最終都還是要整合在一起。

此文分兩個重點部分：『整合』：工程師們如何把自己的產出整合成一個統一版本。『準備發佈』：從整合好的 codebase 到實際上線的分支處理。再深入探討這兩個概念前，有一些基本概念要介紹：

分支 Source Branching

從某個基準點建立新分支以便開發的方式，例如 master 或是 dev 分支的 HEAD 開始開發。這裡的建立新分支可以是 git branch -a 也可以是直接在本地端修改同個分支，所以在本地端的修改不會影響其他人，因為每個人都有自己的 repo。但就算是第二種情境，當大家都在修改同個分支，因為各自都在各自電腦上修改的關係，實際上會產生出各自的不同的分支。

強調不同的分支是因為，最後我們還是需要整合在一起，通常是到 repo 端的來源分支，以上圖為例就是 shared repo master。另，有時候我們講的分支是一個集合體，比如上圖的 Scarlett master, shared repo master, Violet’s master 他們都是 master 分支，為了避免混淆可以使用比較精準的名詞： codeline。Codeline 專指某一個 repo 的分支，不過因為很少人使用 codeline 這個名詞，如果需要區分，通常用『我的 master』、『shared repo master』也是一樣意思。

由於大家都在不同的分支上工作，久了就會產生歧異，而這歧異是會隨著大家不斷提交新變更而越差越遠，如下右圖。也就是說當分支出來越久，合併成本也會持續的提高（後面會有更詳細的探討）。

主線 Mainline

一般會是 shared repo master，或是任何存放團隊整合完畢的程式碼的基準分支。開發的時候可以從這裡開新分支進行，開發完畢則整合回來。主線與 master 是兩個不同的概念，主線代表了目前 codebase 的最新整合結果，而 master 則是代表所有從主線複製出來的不同本機端 master codeline 的集合體。大家要在本地端怎麼亂搞都有可能，因此 master 有可能是許多類似但相異分支的集合。

主線不僅對整合很重要，也是發佈的基準，這在下一部分『準備發布』會有更多探討。

健康分支 Healthy Branch

On each commit, perform automated checks, usually building and running tests, to ensure there are no defects on the branch

由於我們需要確保整個 codebase 是穩定的，沒有（已知）問題的，通常會透過自動化測試來驗證這件事。當然前提是我們對自動化測試的信心，投入足夠多的心力在維持自動化測試包含足夠（但不用過多）的範圍。

理想上我們當然希望每個提交都可以執行測試來確保系統正常，但隨著系統逐漸複雜化，測試開始變多變慢，就會需要有不同的測試策略。如果切分的好，比如說部署前先跑基本的測試，部署與測試也是可以非同步進行的。

除了測試之外還有其他提升『健康度』的方法，比如 code quality、或是下次會提到的 Reviewed Commit 。

主線的健康應該是必要中的必要，如果大家從主線分支出來建立本地端的開發環境時還需要擔心系統跑不起來，那就會拖慢整個開發進度以及發佈速度。如果說開發前還要動改西改才能動，或是東改西改才能發佈，那麼就該花些時間好好的整理主線的健康度。方法之一就是 Self Testing Code，而這也會讓後續的重構變得比較有信心。

對於開發者來說，保持自己本機端分支的健康度也有許多幫助，如果能先確保自己的分支是健康的，那麼未來在整合回主線的時候，遇到錯誤就可以比較輕鬆的處理，因為此時的錯誤多半是整合造成，而不是自己分支本身就有的問題所造成。