Git 開發規範

小江的学习日记發表於2024-08-05
Git

目錄
  • Git 開發規範
    • 分支管理策略
      • git flow
      • github flow
      • gitlab flow
      • trunk-based development
      • 總結
    • Commit Message

Git 開發規範

分支管理策略

git flow

img

Vincent Driessen 於2010年提出的分支模型，可以說是最早、最全面的分支管理策略了，後續出現的分支管理策略基本都是基於 git flow 進行修改的。這裡先要明確幾個基本概念

  1. master/main：主分支，最終所有需要釋出的有效程式碼都會合併到該分支
  2. develop：開發分支，所有開發內容都是基於 develop 分支建立 feature 分支
  3. feature：特性分支，也就是每個版本開發要寫的程式碼
  4. release：釋出分支，當需要釋出版本時，develop 不能直接合併到 master 分支，需要透過 release 分支進行必要測試驗證後，再將 relase 分別合併到 master 和 develop 分支。
  5. hotfix：熱修復分支，線上出了緊急 bug，需要專門分支處理

從上圖可以看出，使用 git flow 開發步驟還是比較多的：

  1. 從 develop 建立一個 feature 分支
  2. 開發並自測完 feature 分支，將其合併到 develop 分支
  3. 從 develop 分支建立 release 分支，進行整合測試
  4. 將 release 分支合併到 master 和 develop 分支

github flow

省略去了大部分分支型別，僅保留了 master 和 feature 分支。

暫時無法在飛書文件外展示此內容

gitlab flow

引入了生產分支和環境分支，總體上與 github flow 區別不大。

環境分支很好理解，即不同環境使用不同的環境分支。

生產分支則類似於 release 分支，但是是從 master 拉取出來，用來代表生產部署的程式碼版本。

trunk-based development

img

與 github flow 差別很大，認為應該在 master（主幹）上開發，使用 release 分支進行釋出，理由是短期的開發任務不需要整的那麼麻煩，測試什麼的在提交到 master 之前做好就行了。

基本上就等同於單分支開發了，用的比較少。

總結

其實分支模型大差不差，git flow 最全面， github flow 最簡化。

基本上，你可以使用 git flow 滿足任何開發團隊的節奏，也可以在此基礎上去掉一些自己不需要使用的分支。github flow 之所以能這麼簡單，主要是因為 feature 分支開發週期較長，且有健全的持續整合、持續部署工具保證 feature 分支合併到 master 後不會影響 master 的可用性，要求不可謂不高。

其實，總結下來，一個健全的開發團隊的分支管理應該滿足以下條件：

  1. 有一個永遠有效、能反應生產部署程式碼的分支，可以隨時釋出
  2. 有一個能持續整合、體現開發進度的分支，能夠幫助提早發現整合問題

Commit Message

很多開發的 git commit message 寫的是一團糟，要麼是流水賬，要麼貨不對板。

commit message 沒有絕對的好壞，但是有相對的優劣，一個團隊要遵守一致的填寫規範。一個好的 commit message 應該要儘可能簡潔、保留關鍵資訊。

我們可以先將 commit 分為幾類：

  1. 程式碼重構：refactor
  2. 功能開發：feat
  3. 問題修復：fix
  4. 檔案變更：doc
  5. ......

先用分類來概括提交內容，再用一段簡短的文字來描述，如：

feat: 考試試卷CRUD

fix: 試卷完成功能失敗問題

refactor: 使用令牌桶替換預設限流演算法

....

相關文章