現在越來越多的專案使用Git作為版本控制的工具，通過Git進行分支和Tag管理，大多數情況這個程序都由手工完成，缺乏相應的規范，對于分支和版本號的控制也很隨意，出現這樣的情況往往是大家對軟體交付程序中的軟體版本控制不夠重視，“只要確保軟體是最新的版本即可”，甚至是專案管理的漏洞或者缺陷，其實軟體的版本控制以及分支管理貫穿于整個軟體產品的生命周期，日常的專案管理對于開發團隊能否有節奏且順利的交付軟體也很重要，

的確！頻繁的沖突搞的開發人員頭暈腦脹，例如，一次專案在代碼合并時出現了沖突，導致整個專案組挨個排查，花費了大半天的時間，影響開發效率還浪費資源；開發人員隨意創建分支，各種不規范的合并使得Git Graph線條雜亂無章，完全看不出來主干發展的脈絡；提交資訊混亂，不知道這次提交是因為什么，實作了什么功能，解決了什么問題，

本文并不是一篇技術文章，其中也沒有讓別人耳目一新的觀點或者論述，本文是為我們這些希望進行簡單、有效地協作的人準備的，任何參與到軟體開發的人，無論承擔何種角色，都可能對其感興趣——畢竟每個人都會用到分支和合并，本文將結合Choerodon豬齒魚為大家闡述如何進行方便有效的分支管理和版本控制，以及如何選擇適合自身的版本控制模型，

如何來解決這些問題呢？

有經驗的老司機可能會說，“建立規范”，

是的，只有建立規范，才能抑制不好的事情繼續在專案組蔓延，至于建立什么樣的規范？我們不妨先制定一個目標，

目標

簡單——所有的團隊成員每天都會使用這些模式，所以相關規則和程式必須要簡單明了，
靈活——可選擇不同的分支管理模型，例如GitFlow、GitLabFlow或者GitHubFlow，甚至自定義，
可視化——界面化比命令列更安全可控，將分支管理模型的規則和約定固化到系統中，
需求與代碼關連——分支需要和具體的任務需求關連，

作為一個有經驗專案管理者，或者產品負責人，你一定會思考一個問題：我們專案組在開發程序中應如何管理分支？不錯，分支管理將和專案組開發人員日夜伴隨，如果采用了一個不合適的分支管理模型，那么可以想象兄弟們得多么的痛苦，

Okay，那么就從分支管理模型開始……

分支管理規范

GitFlow、GitHubFlow等都是已經被證明很有效的分支管理模型，但是這些更多的是書面的規則、約定，基本上是靠著程式員的自覺性和Git命令一起維持著這個約定，其實無數的經驗告訴我們“這很脆弱”，所以，如何使用系統界面化操作將這些規則和約定表示出來，就變得很有意思，

分支管理模型

不要著急，先來看看 Choerodon 豬齒魚提供的分支模型，Choerodon使用 GitLab 進行分支管理，默認分支為 master，目前支持七種常見的分支型別：

master：主分支，用于版本持續發布；
develop：開發分支，即日常迭代使用的開發分支，用于日常開發持續集成；
feature：特性分支，用于日常開發時切出分支進行單功能開發；
bugfix：故障修補分支，通常用于修復故障；
release：發布分支，適用于產品發布、產品迭代；
hotfix：熱修分支，用于產品發布后修復缺陷；
custom：自定義分支，用戶可以自定義需要的分支型別，

注:

develop是GitFlow分支模型的重要組成部分，
bugfix旨在與敏捷的問題型別（故障）呼應，用于標識此分支的任務是修復某個故障，

這7個分支就是我們手中的7個魔方，通過這7個魔方的組合可以變化出無盡的分支管理模型，比如GitHubFlow，

GitHubFlow分支模型只存在一個master主分支，日常開發都合并至master，永遠保持其為最新的代碼，

在領到日常開發任務時，基于master創建feature特性開發分支，提交代碼后，合并至master并洗掉feature，
在領到修復故障的任務時，基于master創建bugfix故障修補分支，提交代碼后，合并至master并洗掉bugfix，
需要發布時，同樣需要基于master創建release，生成的應用版本部署在UAT測驗環境進行測驗，若需要修改則提交至release，
產品上線后發現故障需要緊急進行熱修復時，則基于tag創建hotfix，將修復的代碼提交至hotfix；部署該分支上的版本通過驗收后，基于hotfix打出熱修版本的tag，如0.8.1，
由于新版本的迭代也同時進行，所以需要在hotfix上rebase master，變基至master分支最新的提交，再合并至master并洗掉hotfix，就可以將本次修改的提交應用至master上，

這個分支模型的優勢在于簡潔易理解，將master作為核心的分支，代碼更新持續集成至master上，根據目前收集到的反應來看，得到了更多的好評，認為GitHubFlow分支模型更加輕便快捷，

如果GitHubFlow不合適，可以使用GitLabFlow或者GitFlow，也可以自行定義規則，這里沒有“銀彈”，只是相對比較靈活的配置，

分支命名規約

有了分支管理模型，還需要命名規約，不同型別的分支命名方式應該不同，值得慶幸的是，豬齒魚已經幫你完成了這個步驟，feature、bugfix分支的分支名使用的是關聯問題的issue號（在豬齒魚中打通了需求和代碼分支的關連關系），對于release及hotfix，分支名可命名為需要發布的版本號，如0.8.0、0.8.1等，在這里使用到了類似0.8.0這樣的版本編號規則，如果你對此不了解，沒有關系，在下面將詳細的介紹，

提交命名規約

除了分支的名稱需要規范，提交的命名也同樣如此，不幸，豬齒魚并沒有把這個規則固化到系統中，需要團隊共同遵守，

格式為：[操作型別]操作物件名稱，如[ADD]readme，代表增加了readme描述檔案，

常見的操作型別有：

[IMP] 提升改善正在開發或者已經實作的功能
[FIX] 修正BUG
[REF] 重構一個功能，對功能重寫
[ADD] 添加實作新功能
[REM] 洗掉不需要的檔案

合并請求

合并請求是開發程序中必不可少的一個環節，其中有如下一些重要的事情要做：

代碼Review
啟動CI
- 單元測驗
- 代碼質量檢查

版本號規則

在軟體管理的領域里存在著被稱作“依賴地獄”的死亡之谷，系統規模越大，加入的套件越多，你就越有可能在未來的某一天發現自己已深陷絕望之中，
                              —— Tom Preston-Werner 的《語意化版本2.0.0》

在這里我們不去解讀到底什么是“依賴地獄”，大家可以到語意化版本2.0.0中了解，那么，我們的重點是什么呢？在這之前，先了解一下“語意化的版本控制”

版本格式：主版本號.次版本號.修訂號，版本號遞增規則如下：

1.主版本號：當你做了不兼容的 API 修改，
2.次版本號：當你做了向下兼容的功能性新增，
3.修訂號：當你做了向下兼容的問題修正，

先行版本號及版本編譯資訊可以加到“主版本號.次版本號.修訂號”的后面，作為延伸，

這就是“語意化的版本控制”最核心的規則，當然這不是全部，Tom Preston-Werner還詳細的闡述了主版本號、次版本號和修訂號的變化遞增規則，不過這些規則很長，很復雜，

沒有關系，豬齒魚幫我們做了這些復雜的事情，將“語意化的版本控制”固化到了系統中，簡而言之，

當進行代碼打包時，而非發布新版本

將版本號規則定為年.月.日-時分秒-分支名，如：2018.7.20-152837-hotfix-0.8.1，這個時間是當前提交時間，當代碼提交到各個分支上時會自動觸發CI，生成版本號規則如上所示，

當需要發布新版本時，例如如0.8.0、0.8.1
- 主版本號：當做了不兼容的 API 修改或功能強大的升級，可以將主版本號的數值增加1，
- 次版本號：當做了向下兼容的功能性新增或是功能上的小迭代，可以將次版本號的數值增加1，
- 修訂號：當做了向下兼容的問題修正，但功能上沒有很大的變化，可以將修訂號的數值增加1，

需求與代碼關連

一直以來，需求一般和系統的功能聯系在一起，但是與代碼關連卻不常見，如果能將需求和代碼聯系在一起，奇妙的化學反應就發生了，

“我們可以追溯到一個用戶故事對應了哪些分支，哪幾個提交”， “甚至出現了一些BUG，可以找到是哪個分支提交的，當初為了發布XXX新的需求”， “不僅如此，我們通過需求與代碼分支關連，能夠查看到哪些需求已經部署到了測驗環境，那些需求已經部署到了正式環境”， “可以做從業務到代碼的整個鏈條的統計分析…”

…

這一切，豬齒魚已經幫助專案管理者和程式員實作了，在豬齒魚的敏捷管理服務中，可以通過用戶故事、任務、缺陷等直接一鍵創建分支，然后，你可以從git checkout -b 開始愉快而又有挑戰的一天，不僅如此，也可以在分支管理中，將現有的分支關連到用戶故事、任務或者缺陷，