分支規範

1、目的

 咱們制定分支規範，意在實現如下目標：

1. 減小溝通成本：開發者能夠很清晰地知道須要修改的代碼位於哪一個分支。
2. 減小 bug 隱患：避免因分支合併致使 bug。
3. 維護線上穩定：經過必定的流程規範，保證線上代碼安全。
4. 靈活：支持多版本同時開發、同時發佈。
5. 簡潔：用最少的分支解決問題，避免反覆建立、合併分支，節約操做時間。

2、主分支: 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 分支。

3、開發分支: 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 分支合併最新的改動。

4、修復分支: 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 直到解決。

5、構建分支: 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 時，開發者能夠切到此分支查找問題。

6、其它分支

根據項目實際需求，能夠建立其它分支，如 github 頁面須要的 gh_pages 等分支。

7、總結

分支總共有：master、dev-xx、release-xx、bugfix-xx、build-xx 五類。大部分項目只需建立前面 2 個分支，其他的根據須要再建。開發者平時只需維護 dev-xx 分支。dev-xx 的代碼只能發佈到測試環境，不能直接發佈上線。