GIT分支開發模型

1. 最穩定的程式碼放在 master 分支上（相當於 SVN 的 trunk 分支），我們不要直接在 master 分支上提交程式碼，只能在該分支上進行程式碼合併操作，例如將其它分支的程式碼合併到 master 分支上。

2. 我們日常開發中的 程式碼需要從 master 分支拉一條 develop 分支出來，該分支所有人都能訪問，但一般情況下，我們也不會直接在該分支上提交程式碼，程式碼同樣是從其它分支合併到 develop 分支上去。

3. 當我們需要開發某個特性時，需要 從 develop 分支拉出一條 feature 分支，例如 feature-name1

   與 feature-name2，在這些分支上並行地開發具體特性。

4. 當特性開發完畢後，我們決定需要釋出某個版本了，此時需要從 develop 分支上拉出一條 qa 分支，例如 qa-name1-name2，並將需要釋出的特性從相關 feature 分支一同合併到 qa 分支上，隨後將針對 qa 分支部署測試環境，測試工程師在該分支上做功能測試，開發工程師在該分支上修改 bug。

5. 待測試工程師無法找到任何 bug 時，我們可繼續從 master 分支拉出一條 release 分支，此時release的版本號必須根據master的tag版本號來遞增，遞增規則參見下面版本號規範，例如 release1.0.0

   ，並將qa-name1-name2分支合併到release1.0.0，並部署到預發環境，再次驗證以後，均無任何 bug，此時可將 release 分支部署到生產環境。

6. 待上線完成後，將 release 分支上的程式碼同時合併到 develop 分支與 master 分支，並在 master 分支上打一個 tag，例如 v1.0.0。

7. 當生產環境發現 bug 時，我們需要從對應的 tag 上（例如 v1.0.0）拉出一條 hotfix 分支（例如 hotfix1.0.1），並在該分支上做 bug 修復。待 bug 完全修復後，需將 hotfix 分支上的程式碼同時合併到 develop 分支與 master

   分支。最後，在 master 分支打tag（例如 v1.0.1）。

對於版本號規範：
格式為：x.y.z，其中，x 用於有重大重構時才會升級，y 用於有新的特性發布時才會升級，z 用於修改了某個 bug 後才會升級。

使用GIT管理程式碼應該遵循以下規範：

1. 上傳內容：保證GIT上儲存的是“乾淨”的程式碼，不得有編譯後再次生成的程式碼，如Java位元組碼檔案和JSP生成檔案，也不能有IDE生成檔案；
2. 上傳註釋：必須加簡要的註釋，註釋的內容應包含開發的模組名稱以及功能描述；

   功能提交：[模組名稱]功能描述，如：[使用者模組]使用者列表增加手機號欄位顯示；
   Bug Fix：[模組名稱]Bug-編號：Bug描述，如：[使用者模組]Bug-1203：使用者建立儲存失敗已修復；

3. 上傳質量：提交和合併到分支上的程式碼儘量保證是自己測試通過的程式碼，以免影響別的專案/同事；