我們的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)

標題：專案名-日期