Git flow在實踐中的改進

原文地址: juejin.im/post/5d83ad…

在團隊協做開發中, 各成員須要互相配合來完成功能的開發, 測試和發佈. 但各成員習慣各異, 每一個人對如何協做的理解也不一樣, 所以須要一個協做模型來規範團隊不一樣職能的人員以及相同職能的人員如何配合.

下面將基於Git來進行工做流層面的分析.

傳統的Git flow

比較傳統的一個Git flow是來自Vincent Driessen的分享, 總體交互圖以下:

A successful Git branching model.

在這個模型中, 有兩個主分支和其它功能分支, 主分支包括:

• master: 存放着生產級別的代碼.
• development: 存放着最新開發的,可集成的功能的代碼.

其餘功能分支包括:

• Feature branches: 基於development建立的分支, 用於新功能的開發.
• Release branches: 基於development建立的分支, 用於發佈新的功能, 穩定運行一段時間後合併到master分支, 做爲最終的發佈.
• Hotfix branches: 基於master建立的分支, 用於修復bug.

適用場景分析

這個模型適用的場景有:

• 各階段開發的功能明確: 由於發佈是直接從development中建立新的release分支, 若development中有未完成(開發或測試)的功能則會影響版本的發佈.
• 大量而低頻的發佈: 由於development中可能含有多個功能, 所以須要各功能都測試完畢後才能發佈. 如桌面應用, 移動應用的開發等.

不適用的場景:

• 少許和高頻的發佈.
• 多環境部署(如開發,測試和生產). 如Restful API的開發等.

改進的Git flow

針對傳統Git flow的問題, 改進完後模型以下圖:

該模型包含三個主分支和其餘功能分支, 主分支包括:

• development: 用於新功能的開發端測試(做爲開發者本身測試)和集成(如先後端的API集成).
• staging: 測試分支, 已完成開發端測試和集成的功能分支會合併到這裏, 待測試人員測試.
• production: 生產分支, 存放生產級別代碼; 功能分支經過測試人員在staging環境中的測試後, 將合併到該分支.

development和staging分支的初始化都基於production分支.

其餘功能分支包括:

• Feature branches: 基於production建立的分支, 用於新功能的開發; 命名格式爲feature/feature-name, 如feature/payment;
• Bugfix branches: 基於production建立的分支, 用戶普通bug的修復, 合併流程同feature分支;命名格式爲bugfix/bug-name.
• Hotfix branches: 用於緊急bug的修復, 可直接合並至production分支, 再分別合併到development和staging分支, 命名格式爲hotfix/bug-name.

全部的功能分支都只在開發者本地, 不能上傳到遠程倉庫.

該模型的運行流程以下:

1. 獲得一個功能需求如支付, 基於production分支建立一個新的功能分支feature/payment;
2. 切換到功能分支feature/payment進行開發;
3. 本地開發結束, 將feature/payment分支合併到development分支, 進行開發端測試和集成;
4. 若在開發端測試和集成中發現問題, 切換回feature/payment分支去修復問題, 修復完後執行步驟3;
5. 若在開發端測試和集成中沒有問題, 將feature/payment分支合併到staging分支, 讓測試人員來測試;
6. 若測試人員在staging中發現有關該功能的問題, 切換回feature/payment分支, 修復完後執行步驟3;
7. 若測試人員在staging中認爲該功能已測試完畢, 則將feature/payment分支合併到production分支.

規則

爲了保證該模型的順暢執行, 團隊成員還應遵照如下幾條規則:

1. 全部的功能分支都須要基於最新的production分支建立;
2. 全部的功能分支都只在存在開發者本地, 不能上傳到遠程倉庫, 遠程倉庫只有主分支;
3. 主分支(development, staging和production)之間不能相互合併;
4. 主分支只能合併功能分支(如feature,bugfix和hotfix分支);
5. 功能分支最終要合併到全部的主分支中.
6. 每次合併都要留有記錄(merge命令帶--no-ff);

經過以上改進以後, 該模型就能夠支持多環境部署, 而且保證功能合併的獨立性.

固然, 不一樣團隊的業務場景也有差別, 對各類模型也須要有相應的調整;

總而言之, 沒有絕對完美的模型, 場景決定了適用的模型.

參考

• A successful Git branching model.