高效團隊的gitlab flow最佳實踐

當前git是大部分開發團隊的首選版本管理工具,一個好的流程規範可以讓大家有效地合作,像流水線一樣有條不紊地進行團隊協作。

業界包含三種flow:

  • Git flow
  • Github flow
  • Gitlab flow

下面我們先來分析,然後再基於gitlab flow來設計一個適合我們團隊的git規範。

從git flow到gitlab flow

git flow

先說git flow,大概是這樣的。

gitflow

然後,我們老的git規範是參考git flow實現的。

當前git流程

綜合考慮了開發、測試、新功能開發、臨時需求、熱修復,理想很豐滿,現實很骨幹,這一套運行起來實在是太複雜了。那麼如何精簡流程呢?

我們來看業界的做法,首先是github flow。

github flow

Github flow 是Git flow的簡化版,專門配合”持續發佈”。它是 Github.com 使用的工作流程。

github flow

整個流程:

流程

  • 第一步:根據需求,從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。

gitlab flow

只有緊急情況,才允許跳過上游,直接合併到下游分支。

對於”版本發佈”的項目,建議的做法是每一個穩定版本,都要從master分支拉出一個分支,比如2-3-stable、2-4-stable等等。

版本發佈

gitlab flow 如何處理hotfix? git flow之所以這麼複雜,一大半原因就是把hotfix考慮得太周全了。hotfix的意思是,當代碼部署到產品環境之後發現的問題,需要火速fix。gitlab flow 可以基於後續分支,修改後上線。

團隊git規範

綜合上面的介紹,我們決定採用gitlab flow,按照版本發佈的模式實施,具體來說:

  1. 新的迭代開始,所有開發人員從主幹master拉個人分支開發特性, 分支命名規範 feature-name
  2. 開發完成後,在迭代結束前,合入master分支
  3. master分支合併後,自動cicd到dev環境
  4. 開發自測通過後,從master拉取要發佈的分支,release-$version,將這個分支部署到測試環境進行測試
  5. 測出的bug,通過從release-$versio拉出分支進行修復,修復完成後,再合入release-$versio
  6. 正式發佈版本,如果上線後,又有bug,根據5的方式處理
  7. 等發佈版本穩定後,將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

提交代碼後,可以提交mrmaster,申請合併代碼

mr

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後,刪除分支。


感謝您的認真閱讀。

如果你覺得有幫助,歡迎點贊支持!

不定期分享軟件開發經驗,歡迎關注作者, 一起交流軟件開發:

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章