我們的GIT工作流

dev合併到master觸發ci，預發布

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

git merge --no-ff複製**

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

基於現在的情況與我們團隊習慣，約定可能存在的git分支如下：

prod 用於生產部署, 需要打tag

master 用於ci, 旨在提供乙個穩定的測試環境，合併prod

dev 對本次迭代功能開發合併到master ，開發人員都有許可權

feature 基於dev的下一迭代的功能開發, 乙個功能乙個分支，合併到dev, 名字格式為: feature-$

hotfix 基於prod 修復生產bug ，一次修復迭代(一次上線)乙個分支，合併到prod及dev 名字格式為: hotfix-$-$ tag是要修復的版本的標籤號，index是迭代號，從1開始，作為上線順序

下面詳細說明工作流：

假定本周一確定了這週上線功能，開發人員都明確了自己的開發任務

所有開發人員在dev開發，前端使用mock介面，後端在本地測試介面

後端人員開發完某完整功能的全部介面後，合併**到master, 推送觸發ci，並通知前端人員可對接真實介面

相關前端人員除錯真實介面，完成後，合併到master，推送觸發ci，並通知相關後端人員，相互驗證

如果順利，一切按計畫進行，則周五時相關人員把master分支合併到prod, 並打乙個tag, 方便回滾，之後便可部署到生產

特殊情況一：在週三時，有開發人員接到乙個新需求，該需求下個迭代上線。由於相關開發人員效率高，此時已經把本週功能開發完了，因此決定超前開發，則相關開發人員基於dev分支checkout乙個feature-***的分支，不影響本次發布; 在下次迭代時再合併到dev分支, 合併完後刪除該分支

特殊情況二：下周一在dev開發新功能時，發現上周五發布的版本有兩個bug，需要緊急修復，權衡之後認為，有乙個是當天必須修復的，另乙個需要第二天才能上線，則第乙個bug的分支為hotfix-$-1, 第二個則為hotfix-$-2。則相關人員基於prod checkout兩個分支，進行修改驗證後，合併到dev及prod分支，然後讓相關人員打tag, 發布生產，生產驗證無誤後，刪除分支。

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

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

dev 進行 nightly build. 之前我們也是如此，但這在介面聯調階段，會造成後端一push**，就觸發ci重新構建，導致介面不可用，所有前端都進入阻塞狀態。而後端或測試人員在開發環境驗證期間，前端一push**，導致web應用不可用，所有驗證阻塞。這極大的影響了開發/測試體驗，甚至到了影響心情的地步，因此取消對dev的ci，只對master進行ci

release的命名容易造成誤解。在該文中，release其實是預發布分支，做上線前的驗證用，但我們成員聽上去，誤認為是發布分支，專門做上線發布用。為取消分歧，根據現在團隊的規模，決定用master作為穩定版，作為上線前的驗證分支，而prod則作為真正的上線分支，並在上線前打個tag

tag遵循以下約定

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

內容分類：

示例：以上作為我們的團隊約定，為的是提供協作規範，提高協作效率。這就像寫js**時，到底要不要在後面加分號一樣，並沒有對錯，只是看適不適合你以及你所在的團隊。

我們的GIT工作流

我們的GIT工作流

Git工作流概述

Git 工作流簡介

我們的GIT工作流

我們的GIT工作流

Git工作流概述

Git 工作流簡介

相關推薦