Scrum敏捷開發：Git版本管理流程及規範

分支概述

 

• 分支流程中包含4類分支，分別是master、release、dev、hotfix，各類分支作用和生命週期各不相同。
  • master：該分支是線上穩定版本代碼，禁止提交代碼
  • dev：從master分支切出，是需要開發代碼的分支，所有開發均在dev分支
  • release：從dev分支切出，dev合併到release分支進行測試，同時也是發佈分支
  • hotfix：從master分支切出，解決線上緊急BUG的修復

角色及職責

• 開發組員
  • dev、hotfix的分支開發
  
  
• 開發組長
  • 從master打dev、release、hotfix分支
  • dev、hotfix的分支開發
  • 從dev分支合併到release
  • 從release分支合併到master
  • 將master合併到release分支
  • 刪除hotfix分支

分支記錄存放位置 - Git->wikis->分支記錄

版本號規範

• dev及release版本號命名規則 - <主版本號>.<副版本號>.<發佈號>
  • 主版本號設置規則
    • 產品的主體構件進行重大修改，主版本號加1
    • 產品的主體構件之間的接口協議重大修改，主版本號加1
   
  • 副版本號設置規則
    • 主版本號變更時，副版本號置0
    • 數據結構變更(新增或修改註釋含義的情況除外)，副版本號加1
    • 若副版本號累加至超過90時，採用主版本號進位制，主版本號加1，副版本號重新置0

• • 發佈號設置規則
    • 主版本號或副版本號變更時，發佈號置0
    • 若發佈的版本無數據結構變更，則發佈號加1
  
  
• hotfix版本號命名規則 - <主版本號>.<副版本號>.<發佈號>
  • hotfix由於即修即刪，因此同release版本的版本號即可

主版本號和副版本號的變更標誌着重要的功能或結構變動。發佈號的變更，用於體現小的功能變更

各種場景流程規則

正常開發常規版本

• 當需要開發常規迭代時：

分值類型命名規範創建自合併到備註devdevx.x.xmasterrelease新功能開發完成後提測releaseggreleasex.x.xdevmaster新版本發佈後

• 從master分支創建dev分支，例如：dev1.3.0
• 在dev分支上開發代碼，push到遠程倉庫
• dev分支代碼開發完畢，合併到release分支，例如：release1.3.0 <開發組長>
• 測試人員在release1.3.0分支進行測試，測試完畢後拿release1.3.0分支部署
• 上線驗收完畢後將release1.3.0分支合併到master分支

緊急&BUG修復版本流程規則

• 當需要修復線上緊急BUG時：

分值類型命名規範創建自合併到備註hotfixhotfixmasterreleaseBUG修復後提測

• 從master分支創建hotfix分支
• 在hotfix分支修復BUG，push到遠程倉庫
• BUG修復完畢後切出最新的release分支，例如：release1.3.1 <開發組長>
• 測試人員在release1.3.1分支進行測試，測試完畢後拿release1.3.1分支部署
• 上線驗收完畢後將release1.3.1分支合併到master分支

注意事項

• dev分支之間不能合併代碼
• release分支不能合併到dev分支
• 從dev分支合併到release分支測試時，只能合併dev分支上自己的commit到release，可參考git cherry-pick、git rebase命令
• 如發現當前release分支測試時，落後於master一個版本及以上，需要將master合併至當前release分支；

相關環境 

• 預發佈環境
  • 生產環境
  • 開發環境
  • 測試環境