高效團隊的 gitlab flow 最佳實踐

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

業界包含三種 flow：

下面我們先來分析，然後再看我們團隊基於 gitlab flow 的最佳實踐。

從 git flow 到 gitlab flow

git flow

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

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

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

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

github flow

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

整個流程：

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，按照版本發佈的模式實施，具體來說：

  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

提交代碼後，可以提交 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 分支.

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/98Wa8KVh0yUHLSm1VmO6Aw

猜你喜歡