Git Flow 使用經驗總結

Git Flow 工作流目標

1. 規範分支的使用；
2. 處理線上版本修復和新版本開發並行的情況；
3. 降低開發過程中各成員的處理衝突及合併的成本；（本文針對的目標）

Git Flow 分支簡介

master 分支

• master分支存放的是隨時可供在生產環境中部署的穩定版本程式碼
• master分支儲存官方釋出版本歷史，release tag標識不同的釋出版本
• 一個專案只能有一個master分支
• 僅在釋出新的可供部署的程式碼時才更新master分支上的程式碼
• 每次更新master，都需對master新增指定格式的tag，用於釋出或回滾
• master分支是保護分支，不可直接push到遠端倉master分支
• master分支程式碼只能被release分支或hotfix分支合併

develop 分支

• develop分支是儲存當前最新開發成果的分支
• 一個專案只能有一個develop分支
• develop分支衍生出各個feature分支
• develop分支是保護分支，不可直接push到遠端倉庫develop分支
• develop分支不能與master分支直接互動

feature 分支

• 命名規則：feature/*
• develop分支的功能分支
• feature分支使用develop分支作為它們的父類分支
• 以功能為單位從develop拉一個feature分支
• 每個feature分支顆粒要儘量小，以利於快速迭代和避免衝突
• 當其中一個feature分支完成後，它會合並回develop分支
• 當一個功能因為各種原因不開發了或者放棄了，這個分支直接廢棄，不影響develop分支
• feature分支程式碼可以儲存在開發者自己的程式碼庫中而不強制提交到主程式碼庫裡
• feature分支只與develop分支互動，不能與master分支直接互動 　　 如有幾個同事同時開發，需要分割成幾個小功能，每個人都需要從develop中拉出一個feature分支，但是每個feature顆粒要儘量小，因為它需要我們能儘早merge回develop分支，否則衝突解決起來就沒完沒了。同時，當一個功能因為各種原因不開發了或者放棄了，這個分支直接廢棄，不影響develop分支。

release 分支

• 命名規則：release/，“”以本次釋出的版本號為標識
• release分支主要用來為釋出新版的測試、修復做準備
• 當需要為釋出新版做準備時，從develop衍生出一個release分支
• release分支可以從develop分支上指定commit派生出
• release分支測試通過後，合併到master分支並且給master標記一個版本號
• release分支一旦建立就將獨立，不可再從其他分支pull程式碼
• 必須合併回develop分支和master分支

hotfix 分支

• 命名規則：hotfix/*
• hotfix分支用來快速給已釋出產品修復bug或微調功能
• 只能從master分支指定tag版本衍生出來
• 一旦完成修復bug，必須合併回master分支和develop分支
• master被合併後，應該被標記一個新的版本號
• hotfix分支一旦建立就將獨立，不可再從其他分支pull程式碼

SourceTree 工具功能簡介

1. 將當前倉庫自動初始化 git-flow 規範的結構；
2. 使用git-flow工作流“下一步”選單進行工作流節點的建立及完結。

團隊協作流程

舉例說明feature分支在開發團隊中如何更好的工作

需求

1. 專案當前線上版本 v1.0，待修復bug：樣式調整；
2. 專案計劃下一個版本 v2.0，功能需求：註冊登入、支付；
3. 專案需要並行任務：修復線上bug，開發新版本功能。

協作思路

為減少分支間合併程式碼時的差異，可以通過建立一個專門用來合併用的feature分支，比如ft-merge。其他成員按照自己劃分的功能模組，建立對應的feature分支，根據比如ft-login(註冊登入相關功能,開發者張三)、ft-pay(支付相關功能，開發者李四、王五)。約定每天的同步程式碼任務：張三負責ft-login分支的更新，先從ft-mergepull程式碼到ft-login，解決衝突後merge回ft-merge。李四負責ft-pay，先讓王五提交程式碼到ft-pay，然後從ft-mergepull程式碼到ft-pay，解決衝突後，然後merge回ft-merge。

專案成員及分工

成員	職責	開發分支
劉備	組長，git 分支管理	feature/ft-v20-merge，feature/hotfix-*
關羽	模組責任人，登入註冊	feature/ft-login
趙雲	模組責任人，支付模組（支付寶渠道）開發，當前分支程式碼同步	feature/ft-pay
張飛	支付模組（微信渠道）開發	feature/ft-pay
魏延	支付模組（銀聯渠道）開發	feature/ft-pay
黃忠	支付模組（支付閘道器）開發	feature/ft-pay

協作流程

1. 劉備初始化feature分支:

   • feature/ft-v20-merge
   • feature/ft-login
   • feature/ft-pay
2. 開發者關羽、張飛、趙雲檢出自己負責的分支;
3. 關羽每天上班時 pull ft-v20-merge 分支，下班時 merge 到 ft-v20-merge;
4. 張飛、魏延、黃忠每天上班時 pull ft-pay 分支，下班時 push (這裡是 push) 到 ft-pay;
5. 趙雲每天上班時 pull ft-v20-merge 分支，下班時 merge 到 ft-v20-merge;
6. 劉備每天上班時 檢查 ft-v20-merge 分支分合並記錄，同時review程式碼;
7. 劉備接到線上v1.0 的bug報告，需要修復一個樣式問題， 通過SourceTree git-flow 工作流工具“新建修復補丁”，自動從master檢出修復分支 hotfix/hf-style，進行程式碼修改，測試通過後完成 “修復補丁”生命週期，hf-style分支被合併回develop分支，並將develop分支合併到ft-v20-merge;
8. 關羽和趙雲第二天上班時，同步程式碼，將劉備提交的bug修復內容合併到自己的 feature 分支。
9. 當v2.0版本提測前， 劉備確認各開發者程式碼全部提交，在ft-v20-merge構建提測版本。所有成員跟蹤及修復測試bug，完成測試階段。
10. 劉備通過 SourceTree git-flow 選項“完成功能”，將自動合併ft-v20-merge到develop。
11. 劉備通過 SourceTree git-flow 選項“新建版本”，將自動從develop檢出release/r-v2.0（名稱自己定義），對版本號等資訊等作一些微調後，通過 SourceTree git-flow 選項“完成版本”，自動合併當前分支至master。

流程回放

1. 劉備作為開發組長，可以每天檢查程式碼提交情況。
2. 關羽、趙雲作為功能模組負責人，對合並給到劉備的ft-v20-merge程式碼負責。
3. 張飛、魏延、黃忠作為開發者，不用去關注自己分支和develop分支差異，只需關注每天pull時可能發生的衝突。
4. 劉備作為開發組長，負責線上BUG的修復，合併 hotfix 到 master ，釋出修復版本，並將修復程式碼‘同步’給開發成員。

該流程的特點

1. 減少 feature 分支與 develop 分支互動的頻次，從而降低衝突發生次數，普通開發者只需關注知己負責的分支；
2. 從各個feature-xxx分支直接merge回develop分支改為只由feature-v20-merge merge 回develop分支，develop 合併的質量可以更好地控制。
3. 理論上可以很好的支援跨團隊協作的專案，例如增加曹操負責的開發隊伍加入，只需增加ft-v20-merge-cc（cc表示組長或負責人），操作執行劉備相同的日常操作，等到釋出版本前決定劉備主導合併。