簡述
前陣子，掌上生活iOS客戶端代碼進行了Git遷移。踩了很多坑之后，終于在Git上成功的發布了一個版本，而且還進行了一次緊急發版。所以，趁著下雨的周末，來講講踩完坑之后現在的客戶端Git分支模型。我不會講任何項目的細節，比如為什么模塊化開發，僅討論分支策略和版本管理的相關內容。
新『拿來主義』
業界流行的五分支模型圖如下：
五分支模型對于只管理單個Git倉庫的項目來說，分支非常清晰，版本井井有條。
如果項目被模塊化后，每一個模塊需要被創建Git倉庫，那么，一個項目就會管理多個Git倉庫；
每次項目發版，有些模塊添加了新的功能，這些模塊按照五分支模型需要創建release分支進行發布前的測試；但有些模塊沒有變更，則不需要創建release分支。
這個時候就出現了一個版本中，有些模塊是5分支，有些模塊卻是4分支。
一個項目版本中存在2種分支模型肯定是不允許的，否則版本管理就混亂了。
在項目發版本的時候，如何統一所有模塊倉庫的分支模型呢？
再見release分支
release分支的定義是為新版本的發布做準備的；
它允許我們在最后時刻做一些細小的修改，允許小bug的修復。
release分支是從達到發布理想狀態的develop分支創建出來的；在修復完bug之后，release要合并到master上，同時還要合并到develop上進行代碼同步。
假設，master分支把達到發布理想狀態的develop分支直接合并，創造出預發布版本；那么，release分支所擔當的職責可以由hotfix分支來完成。
按照這個思路，最終確定項目中多Git倉庫下的分支模型。如下圖：
關鍵分支
在整個項目的周期中，原始庫(origin)隨著開發的進行一直保持著2個關鍵分支：
- master分支
- develop分支
每一個開發人員都要了解原始的master分支(origin/master)。
與master分支并行的另一個分支，我們稱為develop分支。
develop分支跟蹤著源碼的最新開發進度，開發人員會不斷的向develop分支合并最新代碼。
當develop分支的源碼到達了一個穩定狀態待發布時，所有的代碼變更需要以某種方式合并到master分支，然后標記一個版本信息。
master分支記錄了所有發布版本的信息，還記錄了每個版本的各個階段，如alpha、beta、rc等。
輔助分支
在這個分支模型中，使用了各種輔助性分支。這些分支與關鍵分支(master和develop)一起，用來支持團隊成員們并行開發，使開發的內容易于追蹤，快速修復內測Bug和線上版本問題。
與關鍵分支不同，這些分支總是有一個有限的生命周期，因為他們最終會被移除。
項目中用到的分支類型包括：
- 特性分支
- 熱修復分支
每一種分支有其特定的目的，并且有嚴格的創建合并規則，比如：可以用哪些分支作為源分支，哪些分支能作為合并目標。當然，從技術角度來看，這些分支絕不是特殊分支。分支的類型基于我們使用的方法來進行分類。它們理所當然是普通的Git分支。
特性分支(feature)
特性分支通常為即將發布或未來發布版本的新功能特性。其命名規則為feature-*。它包含了如下幾種情況：
- 每天開始開發一部分新功能時，需要創建一個特性分支，在完成當天開發任務后，需要合并到develop分支。這種特性分支生命周期比較短，一般不超過一天。
- 在開發的過程中發現一種新的實現方式，為了測試可行性可以創建一個特性分支；最終這個特性分支會根據測試結果合并到develop或取消。
- 有些新功能還無法確定發布時間時，開發這些新功能的特性分支會一直存在下去，直到確定發布時合并到develop分支。
特性分支的實質是只要這個功能處于開發狀態它就會存在，但是最終會合并到develop分支或取消（比如一次令人失望的測試）。
特性分支通常存在于開發者本地的代碼庫中，而不是在源代碼庫中。
當feature分支合并到develop分支上時，我們需要添加一個--no-ff參數，它會在合并過程中強制創建一個空的commit對象，即使該合并操作可以fast-forward。這樣避免了在合并過程中丟失特性分支的歷史信息，將該分支的所有提交組合在一起。
為了詳細說明這種情況，下面有一個比較：
后一種情況，你不可能從Git歷史中一目了然的看出哪些提交一起實現了一個功能，必須手工閱讀全部的日志信息。假如我們需要對整個功能進行回退，后一種方式會是一個非常頭痛的問題，而使用--no-ff參數的情況則非常容易。
熱修復分支(hotfix)
熱修復分支通常為正在內測階段或剛發出的版本修復bug。它的命名規則為hotfix-*。
hotfix分支是從master上分出來的；當完成bug修復后，hotfix分支需要合并到master和develop分支上去，這樣才能保證修復的bug也包含在下一個版本中。
客戶端版本管理
客戶端項目模塊化后，雖然一個項目包含了多個Git倉庫，但是統一了每個倉庫的分支模型后，版本管理就簡單多了。每次發布版本，模塊倉庫根據主倉庫同步打tag，這樣只需要遍歷所有Git倉庫，就可以通過tag拿到任意版本下的所有客戶端代碼。
總結
雖然這個分支模型沒有任何新穎的地方，但是它很好的解決了項目多倉庫情況下版本管理的問題。它讓團隊成員能更多的把精力放在開發上，而不會因倉庫分支不同而不斷在倉庫間同步版本。
