咱們的GIT工做流

概覽

dev合併到master觸發CI，預發佈

下一次迭代功能，也即本次不上線，超前開發的功能，使用feature, 注意使用如下命令合併

git merge --no-ff複製代碼

線上bug使用hotfix修復，合併回prod及dev分支

詳情

基於如今的狀況與咱們團隊習慣，約定可能存在的Git分支以下： 

1. prod 用於生產部署, 須要打tag
   
2. master 用於CI, 旨在提供一個穩定的測試環境，合併prod 
   
3. dev 對本次迭代功能開發 合併到master ，開發人員都有權限 
4. feature 基於dev的下一迭代的功能開發, 一個功能一個分支，合併到dev, 名字格式爲: feature-${根據功能取個英文名字} 
5. hotfix 基於prod 修復生產bug ，一次修復迭代(一次上線)一個分支，合併到prod及dev 名字格式爲: hotfix-${tag}-${index} tag是要修復的版本的標籤號，index是迭代號，從1開始，做爲上線順序
   

下面詳細說明工做流： 

1. 假定本週一肯定了這週上線功能，開發人員都明確了本身的開發任務 
2. 全部開發人員在dev開發，前端使用mock接口，後端在本地測試接口 
3. 後端人員開發完某完整功能的所有接口後，合併代碼到master, 推送觸發CI，並通知前端人員可對接真實接口 
4. 相關前端人員調試真實接口，完成後，合併到master，推送觸發CI，並通知相關後端人員，相互驗證
5. 若是順利，一切按計劃進行，則週五時相關人員把master分支合併到prod, 並打一個tag, 方便回滾，以後即可部署到生產 
6. 特殊狀況一：在週三時，有開發人員接到一個新需求，該需求下個迭代上線。因爲相關開發人員效率高，此時已經把本週功能開發完了，所以決定超前開發，則相關開發人員基於dev分支checkout一個feature-xxx的分支，不影響本次發佈; 在下次迭代時再合併到dev分支, 合併完後刪除該分支 
7. 特殊狀況二：下週一在dev開發新功能時，發現上週五發布的版本有兩個bug，須要緊急修復，權衡以後認爲，有一個是當天必須修復的，另外一個須要次日才能上線，則第一個bug的分支爲hotfix-${tag}-1, 第二個則爲hotfix-${tag}-2。則相關人員基於prod checkout兩個分支，進行修改驗證後，合併到dev及prod分支， 而後讓相關人員打tag,  發佈生產，生產驗證無誤後，刪除分支。

解釋

以上流程及圖片參考了經典文章a-successful-git-branching-model，圖片有部分修改。網上大部分談Git Workflow的文章，思想及內容都源自該文，尤爲是其中的圖片，一度被人稱神。

其實該文有兩點內容是與咱們最佳實踐不符的：

1. dev 進行 nightly build. 以前咱們也是如此，但這在接口聯調階段，會形成後端一push代碼，就觸發CI從新構建，致使接口不可用，全部前端都進入阻塞狀態。然後端或測試人員在開發環境驗證期間，前端一push代碼，致使web應用不可用，全部驗證阻塞。這極大的影響了開發/測試體驗，甚至到了影響心情的地步，所以取消對dev的CI，只對master進行CI
2. release的命名容易形成誤解。在該文中，release實際上是預發佈分支，作上線前的驗證用，但咱們成員聽上去，誤認爲是發佈分支，專門作上線發佈用。爲取消分歧，根據如今團隊的規模，決定用master做爲穩定版，做爲上線前的驗證分支，而prod則做爲真正的上線分支，並在上線前打個tag

標籤

tag遵循如下約定

標籤名：v版本號(major.minor.patch)

標題：項目名-日期

內容分類：

• 新功能
  
• bug修復
  
• 優化
  
• 依賴升級
  
• 重構
  
• 漏洞&補丁
  

示例：

總結

以上做爲咱們的團隊約定，爲的是提供協做規範，提升協做效率。這就像寫js代碼時，到底要不要在後面加分號同樣，並無對錯，只是看適不適合你以及你所在的團隊。