書接上文
在前一篇文章GIT 代碼分支管理模型之一中，我們一起了解了一種叫做“成功的代碼分支管理模型”。在這種模型中，我們確實可以很靈活地應對各種場景下的代碼分支管理。
理想總是那麼美好，而現實偏偏那麼蛋疼！
要用好這種代碼分支管理模型，需要全體開發人員對於GIT有比較深入的瞭解，比如merge, rebase,而且在每一次GIT的操作的時候要很清楚地知道自己正在開發的功能屬於哪個分支的。對於同時開發多個功能點的同事來說，比如同時在開發一個下一版本的功能，以及進行產品線上細微改動的同事來說，確實要非常小心，稍不留神就容易懟錯分支。
歷史背景
在我們公司剛開始推行GIT的時候，領導下的指令是要讓大家把精力全放在功能開發上，對於GIT只需要知道pull 跟push就可以了，經過一段歷史時期的掙扎磨合，無形中我們形成了下面這種分支管理模型，稱之爲 "簡單但囉嗦的分支管理模型"
簡單但囉嗦的分支管理模型
主心骨
這個模型主要有兩種分支，一種叫DEV，一種叫REL。每一種後面都附加有對應版本號，比如DEV1.0, REL1.0
RELx.0
每個版本開始開發之前，都會從上一個版本的REL分支創建出一個新的REL分支，比如REL2.0是從REL1.0創建出來。當然第一個版本REL1.0就是從master分支創建出來的。這樣就確保了每一個版本都是從上一個版本最新代碼創建出來的。
RELx.0神聖職責是作爲每一個大版本發佈的分支，並且是用來部署測試環境，準產品線以及產品線的分支。一般開發人員沒有權限直接往RELx.0上面提交代碼，只能從對應的DEV分支提交代碼，再由集成人員合併到上面去。
DEVx.0
DEVx.0是與RELx.0對應的開發分支，所有開發人員默認都有權限往這個分支上提交代碼。這也是開發人員所需要知道的分支，只需要從這上面pull最新的代碼，然後把本地commit的代碼push到上面去就可以了。
小版本怎麼辦？
在相當長的一段歷史時期中，基本穩定在一個版本一個月左右。但有時會遇到有些小功能着急着上，等不及一個月上一次，所以就有了對應RELx.x以及DEVx.x (x > 0). 比如剛發佈了REL3.0，這時有VIP客戶需要上一個功能，改動不至於很大，但是也等不及下個月再上，於是我們就從REL3.0上面衍生出一條REL3.1的分支。按照之前的規則， REL分支是不允許直接修改代碼的，所有對應的我們會創建DEV3.1的分支，給開發人員在上面進行開發。
在這個過程中，下一版本4.0其實一直在同步進行開發的，但是這時REL4.0以及DEV4.0的分支上是沒有DEV3.1的新功能的，所有在3.1的新功能上線之後，需要由持續集成人員DEV3.1的代碼合併到DEV4.0上面去 （爲什麼不是直接REL3.1到REL4.0呢? 技術上是可行的，但是這樣的話，REL4.0需要反向將代碼合併會DEV4.0去，比較彆扭），持續集成環境會自動將DEV4.0的新代碼合併到REL4.0上面去，這樣到時發佈4.0的時候，纔不會丟失了3.1新增的功能
沒bug的系統是不完整的
有bug怎麼辦？
不管是大版本還是小版本，總有可能產品線上有bug需要hotfix。在上次介紹的成功代碼分支模型中，可以通過hotfix的分支進行代碼修復。但在這個簡單模型中，就不會新建hotfix的分支，而是在最新以上線的分支上進行修改。比如當前產品線上是REL3.0的代碼，REL4.0是下一個大版本，REL3.1是準備上線的小版本，而這時產品上客戶報了Level 1的case，按照SLA需要在三天內修復，我們是等不及REL3.1下週末上的，更不可能等REL4.0到下個月，所有我們要上到3.0的分支上：
- 已上線的REL3.0以及對應的DEV3.0在上線之後就全被鎖掉了，所以這時我們要找代碼集成人員進行解鎖
- 然後在DEV3.0的分支上進行代碼修復，直到測試通過後，合併代碼分支到REL3.0進行緊急上線
簡單但囉嗦
簡單
這種模型中，大部分開發人眼只需要記住版本的DEVx.x就可以了，其它REL什麼的都可以不用管，不懂也沒關係的。
囉嗦
每一個新版本開發前，管理人員都要新建對應的DEV分支，然後開發人員checkout對應分支進行開發。這樣一來，一個版本，無論大小，都需要對應有兩條分支，整個代碼庫看起來就有很多很多的分支，略顯囉嗦。
there is no free lunch!
利弊關係上面已經做了一些簡單的介紹，這種模型適合在項目比較大，團隊人數較多的情況下使用，好處是開發人員不需要對GIT有過深的理解，只需會簡單的pull / push，其它都由分支管理以及對應的權限管理搞定；其缺點也明顯，就是整個代碼庫會有好多好多的分支，看起來比較囉嗦。