當前git是大部分開發團隊的首選版本管理工具，一個好的流程規範可以讓大家有效地合作，像流水線一樣有條不紊地進行團隊協作。
業界包含三種flow：
- Git flow
- Github flow
- Gitlab flow
下面我們先來分析，然後再基於gitlab flow來設計一個適合我們團隊的git規範。
從git flow到gitlab flow
git flow
先說git flow，大概是這樣的。
然後，我們老的git規範是參考git flow實現的。
綜合考慮了開發、測試、新功能開發、臨時需求、熱修復，理想很豐滿，現實很骨幹，這一套運行起來實在是太複雜了。那麼如何精簡流程呢？
我們來看業界的做法，首先是github flow。
github flow
Github flow 是Git flow的簡化版，專門配合”持續發佈”。它是 Github.com 使用的工作流程。
整個流程：
- 第一步：根據需求，從master拉出新分支，不區分功能分支或補丁分支。
- 第二步：新分支開發完成後，或者需要討論的時候，就向master發起一個pull request（簡稱PR）。
- 第三步：Pull Request既是一個通知，讓別人注意到你的請求，又是一種對話機制，大家一起評審和討論你的代碼。對話過程中，你還可以不斷提交代碼。
- 第四步：你的Pull Request被接受，合併進master，重新部署後，原來你拉出來的那個分支就被刪除。（先部署再合併也可。）
github flow這種方式，要保證高質量，對於貢獻者的素質要求很高，換句話說，如果代碼貢獻者素質不那麼高，質量就無法得到保證。
github flow這一套對於庫、框架、工具這樣並非最終應用的產品來說，沒問題，但是，如果如果一個產品是“最終應用”，github flow可能就不合適了。
gitlab flow
Gitlab flow 是 Git flow 與 Github flow 的綜合。它吸取了兩者的優點，既有適應不同開發環境的彈性，又有單一主分支的簡單和便利。它是 Gitlab.com 推薦的做法。
Gitlab flow 的最大原則叫做”上游優先”（upsteam first），即只存在一個主分支master，它是所有其他分支的”上游”。只有上游分支採納的代碼變化，才能應用到其他分支。
對於”持續發佈”的項目，它建議在master分支以外，再建立不同的環境分支。比如，”開發環境”的分支是master，”預發環境”的分支是pre-production，”生產環境”的分支是production。
只有緊急情況，才允許跳過上游，直接合併到下游分支。
對於”版本發佈”的項目，建議的做法是每一個穩定版本，都要從master分支拉出一個分支，比如2-3-stable、2-4-stable等等。
gitlab flow 如何處理hotfix？ git flow之所以這麼複雜，一大半原因就是把hotfix考慮得太周全了。hotfix的意思是，當代碼部署到產品環境之後發現的問題，需要火速fix。gitlab flow 可以基於後續分支，修改後上線。
團隊git規範
綜合上面的介紹，我們決定採用gitlab flow，按照版本發佈的模式實施，具體來說：
- 新的迭代開始，所有開發人員從主幹master拉個人分支開發特性, 分支命名規範 feature-name
- 開發完成後，在迭代結束前，合入master分支
- master分支合併後，自動cicd到dev環境
- 開發自測通過後，從master拉取要發佈的分支，release-$version，將這個分支部署到測試環境進行測試
- 測出的bug，通過從release-$versio拉出分支進行修復，修復完成後，再合入release-$versio
- 正式發佈版本，如果上線後，又有bug，根據5的方式處理
- 等發佈版本穩定後，將release-$versio反合入主幹
最佳實踐
開發feature功能
新建分支，比如feat-test
開發代碼，增加新功能，提交：
@GetMapping(path = "/test", produces = "application/json")
@ResponseBody
public Map<String, Object> test() {
return singletonMap("test", "test");
}
git commit -m "feat: add test code"
git push origin feat-test
提交MR
提交代碼後，可以提交mr到master，申請合併代碼
Note：
- 這裏可以增加自動代碼審查,
合併代碼
研發組長，打開mr，review代碼，可以添加建議：
開發同學根據建議修復代碼，或者線下修改後commit代碼。
研發組長確認沒有問題後，可以合併到master。
合併完成，可以刪除feat分支。
新功能開發好，可以進行提測。
發佈版本
語義化版本號
版本格式：主版本號.次版本號.修訂號，版本號遞增規則如下：
主版本號：當你做了不兼容的 API 修改，
次版本號：當你做了向下兼容的功能性新增，
修訂號：當你做了向下兼容的問題修正。
先行版本號及版本編譯元數據可以加到“主版本號.次版本號.修訂號”的後面，作爲延伸。
主版本號爲0，代表還未發佈正式版本。
測試發佈
master分支，自動部署到開發環境（dev）
功能開發完成，並自測通過後，代碼合併到待發布版本，
分支規則：
release-version
版本規則
主版本號.次版本號
構建時，自動增加修訂號：
主版本號.次版本號.修訂號
從最新的master新拉一個分支release-$version，比如release-0.1
git checkout -b release-0.1
release-$version會自動構建，版本號爲$version.$buildNumber
設定release-$version 分支爲保護分支，不允許直接推送，只能通過merge不允許直接提交代碼，接受MR。
bug修復
需要修改bug時，從release-$version新拉分支，修改完成後再合併到release-$version分支.
-
Q: 從
release-$version拉的分支，如何測試？ -
A: 這個節點定義爲bug修復節點，建議開發同學優先本地測試驗證，嚴重通過再合併到release分支。
-
Q:
release-$version太多怎麼辦？ -
A: 可以保留最近的10個版本。歷史的打tag後，刪除分支。
感謝您的認真閱讀。
如果你覺得有幫助，歡迎點贊支持！
不定期分享軟件開發經驗，歡迎關注作者, 一起交流軟件開發：