最近，團隊新入職了一些小伙伴，在開發過程中，他們問我 Git 分支是如何管理的，以及應該怎么提交代碼？

我大概說了一些規則，但仔細想來，好像也并沒有形成一個清晰規范的流程。所以查了一些資料，總結出下面這篇文章，分享給大家。

Git flow

在這種模式下，主要維護了兩類分支：

主要分支 (The main branch)

• master
• develop

輔助分支 (Supporting branch)

• feature branch (功能分支)
• release branch (預發布分支)
• hotfix branch (熱修復分支)

master

首先，代碼庫應該有一個、且僅有一個主分支。master 分支的代碼永遠是穩定的，可以隨時發布到生產環境。

develop

develop 分支用于日常開發，保存了開發過程中最新的代碼。

當 develop 分支上的代碼達到穩定，并且具備發版狀態時，需要將 develop 的代碼合并到 master，并且打一個帶有發布版本號的 tag。

創建 develop 分支：

git checkout -b develop master

將 develop 合并到 master：

# 切換到 master 分支
git checkout master
# 對 develop 分支進行合并
git merge --no-ff develop

--no-ff 參數的作用是使當前的合并操作總是創建一個新的 commit 對象，即使該合并被執行為快進式（fast-forward）合并。

這樣可以避免丟失掉該功能分支的歷史信息，并且將針對該功能的所有提交都集中到一起。這樣解釋也并不是很易懂，通過下圖來對比一下就比較明顯了：

feature

• 分支來源：develop
• 合并到分支：develop
• 分支命名約定：feature-*

功能分支，在開發某一個新功能時，從 develop 分支分出來，開發完之后，再合并回 develop 分支。

功能分支通常只存在于開發者的本地倉庫中，并不包含在遠程庫中。

創建一個功能分支：

git checkout -b feature-x develop

開發完成后，將功能分支合并到 develop 分支：

git checkout develop

git merge --no-ff feature-x

刪除 feature 分支：

git branch -d feature-x

release

• 分支來源：develop
• 合并到分支：develop，master
• 分支命名約定：release-*

預發布分支，它是指發布正式版本之前，我們可能需要有一個預發布的版本測試，并且可以在上面做一些較小 bug 的修復。

預發布分支是從 develop 分支上分出來的，預發布結束以后，必須合并進 develop 和 master 分支。

創建一個預發布分支：

git checkout -b release-1.2 develop

確認沒有問題后，合并到 master 分支：

git checkout master

git merge --no-ff release-1.2
# 對合并生成的新節點，做一個標簽
git tag -a 1.2

再合并到 develop 分支：

git checkout develop

git merge --no-ff release-1.2

最后，刪除預發布分支：

git branch -d release-1.2

hotfix

• 分支來源：master
• 合并到分支：develop，master
• 分支命名約定：hotfix-*

最后一種是修復 bug 分支。軟件正式發布以后，難免會出現 bug。這時就需要創建一個分支，進行 bug 修復。

修復 bug 分支是從 master 分支上分出來的。修復結束以后，再合并進 master 和 develop 分支。

創建一個修復 bug 分支：

git checkout -b hotfix-0.1 master

修復結束后，合并到 master 分支：

git checkout master

git merge --no-ff hotfix-0.1

git tag -a 0.1.1

再合并到 develop 分支：

git checkout develop

git merge --no-ff hotfix-0.1

最后，刪除修復 bug 分支：

git branch -d hotfix-0.1

小結

優點：

各分支權責分明，清晰可控，是很多分支管理策略的啟蒙模型。

缺點：

合并沖突：同時長期存在的分支可能會很多：master、develop、release、hotfix、若干并行的 feature 分支。兩兩之間都有可能發生沖突。頻繁手動解決沖突不僅增加工作量，而且增大了出錯的風險。

功能分離：功能并行開發時，合并分支前無法測試組合功能，而且合并后可能會出現互相影響。

無法持續交付：Git flow 更傾向于按計劃發布，一個 feature 要經歷很多步驟才能發布到正式環境，難以達到持續交付的要求。

無法持續集成：持續集成鼓勵更加頻繁的代碼集成和交互，盡早解決沖突，而 Git flow 的分支策略隔離了代碼，盡可能推遲代碼集成。

Github flow

Github flow 是一個輕量級的基于分支的工作流程。它由 GitHub 在 2011 年創建。分支是 Git 中的核心概念，并且 GitHub 工作流程中的一切都以此為基礎。

它只有一個長期分支 master，其他分支都在其基礎上創建。使用流程如下：

根據需求，從 master 拉出新分支，不用區分功能分支或修復分支，但需要給出描述性的名稱。

本地的修改直接提交到該分支，并定期將其推送到遠程庫上的同一命名分支。

新分支開發完成后，或者需要討論的時候，向 master 發起一個 Pull Request（簡稱 PR）。

Pull Request 既是一個通知，讓別人注意到你的請求，又是一種對話機制，大家一起評審和討論你的代碼。對話過程中，你還可以不斷提交代碼。

你的 Pull Request 被接受，合并進 master，重新部署后，原來你拉出來的那個分支就被刪除了。

小結：

優點：

降低了分支管理復雜度，更適合小型團隊，或者維護單個版本的項目開發。

工作流程簡單，對持續交付和持續集成友好。

缺點：

無法支持多版本代碼部署。

Gitlab flow

它是 Git flow 與 Github flow 的綜合。吸取了兩者的優點，既有適應不同開發環境的彈性，又有單一主分支的簡單和便利。

Gitlab flow 和 Github flow 之間的最大區別是 Gitlab flow 支持環境分支。

Gitlab flow 的最大原則叫做"上游優先"（upsteam first），即只存在一個主分支 master，它是所有其他分支的"上游"。只有上游分支采納的代碼變化，才能應用到其他分支。

Gitlab flow 分成兩種情形來應付不同的開發流程：

• 持續發布
• 版本發布

持續發布

對于持續發布的項目，它建議在 master 分支以外，再建立不同的環境分支，每個環境都有對應的分支。比如，開發環境的分支是 master，預發環境的分支是 pre-production，生產環境的分支是 production。

開發分支 master 用于發布到測試環境，該分支為受保護的分支。

預發分支 pre-production 用于發布到預發環境，上游分支為 master。

正式分支 production 用于發布到正式環境，上游分支為 pre-production。

如果生產環境（production）發生錯誤，則要建一個新分支修改完后合并到最上游的開發分支（master）此時就是（Upstream first），且經過測試，再繼續往 pre-production 合并，要經過測試沒有問題了才能夠再往下合并到生產環境。

版本發布

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

在出現 bug 后，根據對應的 release branch 創建一個修復分支，修復工作完成后，一樣要按照上游優選的原則，先合并到 master 分支，經過測試才能夠合并到 release 分支，并且此時要更新小版本號。

小結

優點：

• 可以區分不同的環境部署。
• 對持續交付和持續集成友好。

缺點：

分支多，流程管理復雜。

TrunkBased

Trunk Based Development，又叫主干開發。開發人員之間通過約定，向被指定為主干，一般為 master，的分支提交代碼，以此來抵抗因為長期存在的多分支導致的開發壓力。這樣可以避免分支合并的困擾，保證隨時擁有可發布的版本。

使用主干開發后，只有一個 master 分支了，所有新功能也都提交到 master 分支上，保證每次提交后 master 分支都是可隨時發布的狀態。

沒有了分支的代碼隔離，測試和解決沖突都變得簡單，持續集成也變得穩定了許多，但也有如下幾個問題：

• 如何避免發布的時候引入未完成的 feature
• 如何進行線上 bug fix

如何避免發布的時候引入未完成的 feature

答案是：Feature Toggle。

既然代碼要隨時保持可發布，而我們又需要只有一份代碼來支持持續集成，在代碼庫里加一個特性開關來隨時打開和關閉新特性是最容易想到的，當然也是最容易被質疑的解決方案。

Feature Toggle 是有成本的，不管是在加 Toggle 的時候的代碼設計，還是在移除 Toggle 時的人力成本和風險，都是需要和它帶來的價值進行衡量的。

事實上，在我們做一個前端的大特性變更的時候，我們確實因為沒辦法 Toggle 而采用了一個獨立的 feature 分支，我們認為即使為了這個分支單獨做一套 Pipeline，也比在前端的各種樣式間添加移除 Toggle 來得簡單。

但同時，團隊商議決定在每次提交前都要先將 master 分支合并到 feature 分支，以此避免分支隔離久以后合并時的痛苦。

如何進行線上 bug fix

在發布時打上 release tag，一旦發現這個版本有問題，如果這個時候 master 分支上沒有其他提交，可以直接在 master 分支上 hot fix，如果 master 分支已經有了提交就要做以下四件事：

• 從 release tag 創建發布分支。
• 在 master 上做 bug fix 提交。
• 將 bug fix 提交 cherry-pick 到 release 分支。
• 在 release 分支再做一次發布。

線上 fix 通常都比較緊急。看完這個略顯繁瑣的 bug fix 流程，你可能會問為什么不在 release 分支直接 fix，再合并到 master 分支？

這樣做確實比較符合直覺，但事實是，如果在 release 分支做 fix，很可能會忘了合并回 master。

試想深夜兩點你做完 bug fix 眼看終于上線成功，這時你的第一反應就是“終于可以下班了。什么，合并回 master？ 明天再來吧“

等到第二天你早已把這個事忘得一干二凈。而問題要等到下一次上線才會被暴露出來，一旦發現，而這個時候上一次 release 的人又不在，無疑增加了很多工作量。

總結

以上四種就是目前相對主流的分支管理策略，但沒有哪一種策略是萬能的。所以無論選擇哪一種，都需要考慮團隊的實際情況，以及項目的具體業務需求，適合自己的才是最好的。

最后，再分享三點小建議：

• 臨時分支不應該存在太久，每個分支應盡量保持精簡，用完即刪
• 工作流應該盡量簡單，同時方便回滾
• 工作流程應該符合我們的項目發布計劃