Git Flow 使用經驗總結

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(支付相關功能，開發者李4、王五)。約定天天的同步代碼任務：張三負責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表示組長或負責人），操做執行劉備相同的平常操做，等到發佈版本前決定劉備主導合併。