高效團隊的gitlab flow最佳實踐
當前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後,刪除分支。
感謝您的認真閱讀。
如果你覺得有幫助,歡迎點贊支援!
不定期分享軟體開發經驗,歡迎關注作者, 一起交流軟體開發: