一、目的 我們制定分支規範，意在實現以下目標： 二、主分支: master 主分支(master)用於存放最新的穩定版本。 正式發佈時：在主分支上創建標簽(tag)。如果發佈非常頻繁可以不加。 標簽的命名規範為：release-v版本號-日期(如 release-v0.0.1-20161010)。業 ...
一、目的
我們制定分支規範，意在實現以下目標：
- 減少溝通成本：開發者可以很清晰地知道需要修改的代碼位於哪個分支。
- 減少 bug 隱患：避免因分支合併導致 bug。
- 維護線上穩定：通過一定的流程規範，保證線上代碼安全。
- 靈活：支持多版本同時開發、同時發佈。
- 簡潔：用最少的分支解決問題，避免反覆創建、合併分支，節約操作時間。
二、主分支: master
主分支(master)用於存放最新的穩定版本。
正式發佈時：在主分支上創建標簽(tag)。如果發佈非常頻繁可以不加。
標簽的命名規範為：release-v版本號-日期(如 release-v0.0.1-20161010)。業務項目可以不加版本號；框架、工具項目可以不加日期。
release-xx 分支：如果需要同時維護多個發佈版本（比如有些框架在發佈新版同時還會更新老版），則需要基於 master 分支創建名為 release-v版本號首碼(如 release-v1.x)的分支，之後 master 分支持續更新為最新穩定版，release-xx 分支則持續更新為對應版本的最新穩定版。所有 release-xx 分支和 master 分支地位相同，master 相當於是 release-latest 分支。
三、開發分支: dev-xx
dev 分支用於存放最新代碼(可能包含未測試的代碼)，只有需要正式發佈時才會合併到 master 分支。
如果項目對穩定性要求不高（比如小項目、練慣用的代碼），則可以不建 dev-xx 分支，而直接在 master 分支修改。
開發時：基於 master 分支創建名為 dev-v版本號(如 dev-v0.0.1)的分支。業務項目可以不加版本號，固定為 dev 分支。
開發完成後發佈測試：直接發佈 dev 分支到測試環境。如果測試出現 bug 則在 dev 分支繼續修複。
測試完成後正式發佈：將 dev 分支合併到 master 分支。然後發佈 master 分支。
如果需要同時開發多個版本，可以從 master 創建多個不同版本號的 dev-xx 分支。每次發佈後其它 dev-xx 分支需要從 master 分支合併最新的改動。
四、修複分支: bugfix-xx
發佈後線上發現 bug 時：
- bug 影響不大：建議在 dev-xx 分支中修複，等待下次發佈時修複。
- bug 影響很大：將線上代碼回滾到 master 分支的上一個標簽(或最近的 release-xx 分支)。
- bug 影響一般：從 master 分支創建名為 bugfix-時間(如 bugfix-20161010190000) 的分支，在此分支修複 bug，修複完成後直接將 bugfix-xx 分支發佈上線。如果上線後 BUG 已解決則將 bugfix-xx 分支合併到 master 分支並刪除 bugfix-xx 分支。如果 bug 仍未解決，則繼續在此分支修複 bug 直到解決。
五、構建分支: build-xx
有些項目需要預編譯(壓縮、優化)代碼才能發佈上線，所有分支在發佈時都會先合併到同名的 build-xx 分支。
如 dev-0.0.1 在發佈測試環境時，需要先合併到 build-dev-0.0.1 分支，然後經過預編譯後發佈 build-dev-0.0.1 分支。
如 dev-0.0.1 在發佈正式環境時，需要先合併到 master 分支，然後合併到 build-master 分支，然後經過預編譯後發佈 build-master 分支。
build-xx 分支可以使用構建工具自動維護。大部分情況開發者不需要關心此分支，除非發現因自動構建導致的 bug 時，開發者可以切到此分支查找問題。
六、其它分支
根據項目實際需求，可以創建其它分支，如 github 頁面需要的 gh_pages 等分支。
七、總結
分支總共有：master、dev-xx、release-xx、bugfix-xx、build-xx 五類。大部分項目只需創建前面 2 個分支，其餘的根據需要再建。開發者平時只需維護 dev-xx 分支。dev-xx 的代碼只能發佈到測試環境，不能直接發佈上線。
