git工做流

gitflow工做流

公司以前採用svn進行維護代碼，最近纔開始進行轉變到用git 進行維護，在學習的過程當中對比了一番最終選擇採用gitflow工做流進行管控，
具體介紹以下：



**master分支**:主分支，可隨時交付給用戶使用的版本

**dev分支**：開發分支，項目組內用於開發的分支，而且保證該分支代碼是可運行

**feature分支**：功能分支，項目中開發新需求或者修改bug都在此分支上進行。

**release分支**:測試分支，開發完成以後，基於dev建立該分支

**hotfix分支**:bug修復分支，用於修復bug，發現bug建立此分支進行修復，基於release或者master分支建立

因爲如今處於開發階段故如今對分支的維護方面沒有那麼完善，並且公司內部沒有測試人員，如今的測試流程都是寫完代碼內部本身進行測試，如今進行開發的時候通常都是基於dev分支建立feature分支：


**建立feature分支以及合併方案**

* 當前處於dev分支或者release分支，基於dev或者release建立新分支

* 建立新功能分支而且切換到該分支,當該功能開發完畢以後，若是該功能開發週期較長，天天從dev分支合併到功能分支上，避免跟dev分支差別較大
* 當功能開發完成合併到dev或者release分支當中，完成以後刪除本地分支，避免本地分支過多，分不清功能是否合併。

**建立release分支以及合併方案**

* 當前處於dev分支當中，基於dev分支建立release分支
* 建立該分支以後，進行打包發佈測試，若是測試當中發現bug，建立hotfix分支，進行修復bug，建立hotfix分支主要想的是多人開發過程當中，發現那個模塊誰負責，誰去修改bug
* 當該分支測試完成以後合併到master和dev分支當中

**建立hotfix分支以及合併方案**
* 當前處於release分支或者master分支當中
* 當release分支發現bug以後，根據release分支建立該分支，進行修復bug。
* 該分支修改完成以後若是是release的bug合併到release分支就可，若是是基於master分支建立的還須要合併到dev分支當中

**命名規則**

分支命名方式採用以下規則
例如: add_user_20180302
add：表明工做類型user表明具體功能模塊：
user:具體的功能模塊
20180302:分支建立時間

**git註釋提交規範**

註釋提交採用以下規則
例如:[修復bug]：bug號
1.修復的具體功能

****

基於上述規範根據咱們項目組的狀況，建立了以下三個版本的分支結構以下:

* master分支


**master分支**

基礎版本分支，開發一些通用功能（目前全部工做都是在此版本開發）

**master分支維護**

master版本維護分如如下：
dev
release/
hotfix/
feature/

 

**開發注意事項**

根據不一樣的業務建立分支的時候選擇建立不一樣的分支，例如master分支在進行建立功能分支的時候應該是：

* feature/add_user_0302

_注：若是您有更好的方案還請留言告知_