June's Blog

簡介: 為統一團隊 git 分支管理規範，剛開始準備自己寫，在網上搜了下，發現不少不錯的 git 分支管理實踐

參考團隊的目前使用方式，更貼近於 git-flow，目前欠缺的是 從 dev 到 master 之間用於發布前準備的 release 分支

最後我為團隊選擇了這個 git 分支管理實踐 A successful Git branching model)，網上有不少參考這篇文章寫的中文版 gitflow 實踐，推薦一個中文版的 Git 最佳實踐：有效的 Git 分支模式)

常用的 git flow 的幾種有 git-flow, github-flow, gitlab-flow

轉載一篇文章: 一文弄懂 Gitflow、Github flow、Gitlab flow 的工作流

此外，可以借助工具gitflow 方便規範使用 git-flow 分支管理模式

GitHub Flow#

特點：#

 以部署為中心的開發模式, 通過簡單的功能和規則，持續且高速 安全地進行部署

• master 分支時常保持可以部署的狀態
• 進行新的作業時要從 master 分支創建新的分支，新分支名稱要具有描述性
• 與 master 分支合併後，立刻部署

前提條件#

• 部署作業完全自動化。必須自動化，一天之類需要多次部署
• 重視測試
  • 讓測試自動化
  • 編寫測試代碼，通過全部測試
  • 維護測試代碼

Git Flow#

荷蘭程序員 Vincent Driessen 曾發表了一篇博客，讓一個分支策略廣為人知。具體流程見下圖（引用該博客的一幅圖片）

高清无码 pdf： https://nvie.com/files/Git-branching-model.pdf

在 Git Flow 中，這 master 和 develop 兩個分支至關重要，它們會貫徹整個流程始終，絕對不會被刪除，同時絕不允許開發者直接進行修改和提交

要以 develop 分支為起點新建 feature 分支，在 feature 分支中進行新功能的開發或者代碼的修正。也就是說 develop 分支維繫著開發過程中的最新代碼，以便程序員創建 feature 分支進行自己的工作

規範#

主分支 master#

首先，代碼庫應該有一個、且僅有一個主分支。所有提供給用戶使用的正式版本，都在這個主分支上發布

開發分支 develops#

主分支只用來分布重大版本，日常開發應該在另一條分支上完成。我們把開發用的分支，叫做 Develop

臨時性分支#

使用完以後，應該刪除，使得代碼庫的常設分支始終只有 Master 和 Develop。

• 功能（feature）分支

• 從某種特定功能，從 Develop 分支上面分出來的。開發完成後，要再並入 Develop

• 預發布（release）分支

• 它是指發布正式版本之前（即合併到 Master 分支之前），我們可能需要有一個預發布的版本進行測試

  預發布分支是從 Develop 分支上面分出來的，預發布結束以後，必須合併進 Develop 和 Master 分支。它的命名，可以採用 release-* 的形式

• 修補 bug（fixbug）分支

• 修補 bug 分支是從 Master 分支上面分出來的。修補結束以後，再合併進 Master 和 Develop 分支。它的命名，可以採用 fixbug-* 的形式

Git-flow 簡單示例#

詳細使用方法可以參考： https://jeffkreeftmeijer.com/git-flow/

mac 使用 homebrew 安裝 git-flow :

brew install git-flow

初始化項目：git flow init#

在 feature 分支中工作開發流程：git flow feature start xxxx#

• 從 develop 分支創建 feature 分支
• 從 feature 分支中實現目標功能
• 通過 Github 向 develop 發送 pull request
• 接受其他開發者審核後，將 Pull Request合併至 develop 分支

feature 功能開發完成後: git flow feature finish xxxx

Develop 分支受保護，建議先 push feature 分支到 remote，再提交 pr 合併至 dev 分支

保留原分支命令： git flow feature finish -k my-feature

Reference： https://github.com/nvie/gitflow/wiki/Command-Line-Arguments

在 gitlab 或者 paas 上提交 pr

!!!! Import : 更新本地的 develop 分支

我們發送的 pull request 在 github 端與 develop 合併後，為了讓其反應到本地的 develop 分支中，我們需要進行以下操作：

• 切換到 develop 分支
• 執行 git pull (fetch & merge)

每當需要從 develop 分支創建 feature 等分支時，記得一定要先執行上述操作，保證 develop 分支處於最新狀態

發版準備#

創建 release 分支 ，在這個分支，我們只處理與發布前準備相關的提交，比如版本編號變更的元數據的添加工作。如果軟件部署到預演環境後測試出 bug，相關修正也要提交到這個分支。

注意：該分支絕對不能包含需求變更或者功能變更等重大修正。這一階段的提交數應該限制到最低

當所有修正處理完後，我們結束這分支

常見問題及解決思路#

特性分支合併衝突#

問題：在完成特性分支並嘗試合併到 develop 分支時，可能會遇到合併衝突。

解決辦法：

• 在合併前確保 develop 分支的最新更改已經拉取到本地。
• 使用 git merge --no-ff <feature-branch> 來執行合併，這樣可以在歷史記錄中保留合併操作。
• 手動解決衝突，使用 git add <conflicted-file> 添加解決衝突的文件，然後 git commit 提交合併。

特性分支太多，難以管理#

問題：隨著時間的推移，項目中可能積累了大量的特性分支。

解決辦法：

• 定期清理不再需要的特性分支。
• 使用 git branch -d <feature-branch> 刪除本地分支，使用 git push --delete origin <feature-branch> 刪除遠程分支。
• 對團隊成員進行培訓，強調完成或廢棄特性分支的重要性。

發布分支合併問題#

問題：在準備發布時，從 develop 分支創建的 release 分支可能會在合併到 master 和 develop 時出現問題。

解決辦法：

• 在創建發布分支之前，確保 develop 分支是穩定的。
• 在合併到 master 之前，確保所有的測試都通過。
• 使用 git flow release finish 命令時，仔細檢查自動生成的合併請求。

緊急修復分支管理#

問題：緊急修復需要快速合併到 master 和 develop 分支。

解決辦法：

• 使用 git flow hotfix start <hotfix> 快速創建熱修復分支。
• 完成修復後，使用 git flow hotfix finish <hotfix> 命令，確保合併到 master 和 develop。
• 確保在合併後更新版本號和相關文檔。

多個團隊協作衝突#

問題：在大型項目中，多個團隊可能在同一時間工作在不同的特性分支上。

解決辦法：

• 使用合併請求（Pull Requests）來進行代碼審查和合併。
• 定期召開團隊會議，討論進度和潛在的合併衝突。
• 使用標籤和里程碑來跟蹤各個團隊的工作進度。