最近，團(tuán)隊(duì)新入職了一些小伙伴，在開發(fā)過程中，他們問我 Git 分支是如何管理的，以及應(yīng)該怎么提交代碼？

我大概說了一些規(guī)則，但仔細(xì)想來，好像也并沒有形成一個(gè)清晰規(guī)范的流程。所以查了一些資料，總結(jié)出下面這篇文章，一共包含四種常見的分支管理策略，分享給大家。

Git flow

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

• 主要分支 (The main branch)masterdevelop
• 輔助分支 (Supporting branch)feature branch (功能分支)release branch (預(yù)發(fā)布分支)hotfix branch (熱修復(fù)分支)

master

首先，代碼庫應(yīng)該有一個(gè)、且僅有一個(gè)主分支。master 分支的代碼永遠(yuǎn)是穩(wěn)定的，可以隨時(shí)發(fā)布到生產(chǎn)環(huán)境。

develop

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

當(dāng) develop 分支上的代碼達(dá)到穩(wěn)定，并且具備發(fā)版狀態(tài)時(shí)，需要將 develop 的代碼合并到 master，并且打一個(gè)帶有發(fā)布版本號的 tag。

創(chuàng)建 develop 分支：

git checkout -b develop master

將 develop 合并到 master：

# 切換到 master 分支git checkout master# 對 develop 分支進(jìn)行合并git merge --no-ff develop

–no-ff 參數(shù)的作用是使當(dāng)前的合并操作總是創(chuàng)建一個(gè)新的 commit 對象，即使該合并被執(zhí)行為快進(jìn)式（fast-forward）合并。

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

feature

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

功能分支，在開發(fā)某一個(gè)新功能時(shí)，從 develop 分支分出來，開發(fā)完之后，再合并回 develop 分支。

功能分支通常只存在于開發(fā)者的本地倉庫中，并不包含在遠(yuǎn)程庫中。

創(chuàng)建一個(gè)功能分支：

git checkout -b feature-x develop

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

git checkout developgit merge --no-ff feature-x

刪除 feature 分支：

git branch -d feature-x

release

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

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

預(yù)發(fā)布分支是從 develop 分支上分出來的，預(yù)發(fā)布結(jié)束以后，必須合并進(jìn) develop 和 master 分支。

創(chuàng)建一個(gè)預(yù)發(fā)布分支：

git checkout -b release-1.2 develop

確認(rèn)沒有問題后，合并到 master 分支：

git checkout mastergit merge --no-ff release-1.2# 對合并生成的新節(jié)點(diǎn)，做一個(gè)標(biāo)簽git tag -a 1.2

再合并到 develop 分支：

git checkout developgit merge --no-ff release-1.2

最后，刪除預(yù)發(fā)布分支：

git branch -d release-1.2

hotfix

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

最后一種是修復(fù) bug 分支。軟件正式發(fā)布以后，難免會出現(xiàn) bug。這時(shí)就需要創(chuàng)建一個(gè)分支，進(jìn)行 bug 修復(fù)。

修復(fù) bug 分支是從 master 分支上分出來的。修復(fù)結(jié)束以后，再合并進(jìn) master 和 develop 分支。

創(chuàng)建一個(gè)修復(fù) bug 分支：

git checkout -b hotfix-0.1 master

修復(fù)結(jié)束后，合并到 master 分支：

git checkout mastergit merge --no-ff hotfix-0.1git tag -a 0.1.1

再合并到 develop 分支：

git checkout developgit merge --no-ff hotfix-0.1

最后，刪除修復(fù) bug 分支：

git branch -d hotfix-0.1

小結(jié)

優(yōu)點(diǎn)：

1. 各分支權(quán)責(zé)分明，清晰可控，是很多分支管理策略的啟蒙模型。

缺點(diǎn)：

1. 合并沖突：同時(shí)長期存在的分支可能會很多：master、develop、release、hotfix、若干并行的 feature 分支。兩兩之間都有可能發(fā)生沖突。頻繁手動解決沖突不僅增加工作量，而且增大了出錯(cuò)的風(fēng)險(xiǎn)。
2. 功能分離：功能并行開發(fā)時(shí)，合并分支前無法測試組合功能，而且合并后可能會出現(xiàn)互相影響。
3. 無法持續(xù)交付：Git flow 更傾向于按計(jì)劃發(fā)布，一個(gè) feature 要經(jīng)歷很多步驟才能發(fā)布到正式環(huán)境，難以達(dá)到持續(xù)交付的要求。
4. 無法持續(xù)集成：持續(xù)集成鼓勵(lì)更加頻繁的代碼集成和交互，盡早解決沖突，而 Git flow 的分支策略隔離了代碼，盡可能推遲代碼集成。

GitHub flow

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

它只有一個(gè)長期分支 master，其他分支都在其基礎(chǔ)上創(chuàng)建。使用流程如下：

1. 根據(jù)需求，從 master 拉出新分支，不用區(qū)分功能分支或修復(fù)分支，但需要給出描述性的名稱。
2. 本地的修改直接提交到該分支，并定期將其推送到遠(yuǎn)程庫上的同一命名分支。
3. 新分支開發(fā)完成后，或者需要討論的時(shí)候，向 master 發(fā)起一個(gè) Pull Request（簡稱 PR）。
4. Pull Request 既是一個(gè)通知，讓別人注意到你的請求，又是一種對話機(jī)制，大家一起評審和討論你的代碼。對話過程中，你還可以不斷提交代碼。
5. 你的 Pull Request 被接受，合并進(jìn) master，重新部署后，原來你拉出來的那個(gè)分支就被刪除了。

小結(jié)：

優(yōu)點(diǎn)：

1. 降低了分支管理復(fù)雜度，更適合小型團(tuán)隊(duì)，或者維護(hù)單個(gè)版本的項(xiàng)目開發(fā)。
2. 工作流程簡單，對持續(xù)交付和持續(xù)集成友好。

缺點(diǎn)：

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

Gitlab flow

它是 Git flow 與 Github flow 的綜合。吸取了兩者的優(yōu)點(diǎn)，既有適應(yīng)不同開發(fā)環(huán)境的彈性，又有單一主分支的簡單和便利。

Gitlab flow 和 Github flow 之間的最大區(qū)別是 Gitlab flow 支持環(huán)境分支。

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

Gitlab flow 分成兩種情形來應(yīng)付不同的開發(fā)流程：

• 持續(xù)發(fā)布
• 版本發(fā)布

持續(xù)發(fā)布

對于持續(xù)發(fā)布的項(xiàng)目，它建議在 master 分支以外，再建立不同的環(huán)境分支，每個(gè)環(huán)境都有對應(yīng)的分支。比如，開發(fā)環(huán)境的分支是 master，預(yù)發(fā)環(huán)境的分支是 pre-production，生產(chǎn)環(huán)境的分支是 production。

• 開發(fā)分支 master 用于發(fā)布到測試環(huán)境，該分支為受保護(hù)的分支。
• 預(yù)發(fā)分支 pre-production 用于發(fā)布到預(yù)發(fā)環(huán)境，上游分支為 master。
• 正式分支 production 用于發(fā)布到正式環(huán)境，上游分支為 pre-production。

如果生產(chǎn)環(huán)境（production）發(fā)生錯(cuò)誤，則要建一個(gè)新分支修改完后合并到最上游的開發(fā)分支（master）此時(shí)就是（Upstream first），且經(jīng)過測試，再繼續(xù)往 pre-production 合并，要經(jīng)過測試沒有問題了才能夠再往下合并到生產(chǎn)環(huán)境。

版本發(fā)布

對于版本發(fā)布的項(xiàng)目，建議的做法是每一個(gè)穩(wěn)定版本，都要從 master 分支拉出一個(gè)分支，比如 2-3-stable、2-4-stable 等。

在出現(xiàn) bug 后，根據(jù)對應(yīng)的 release branch 創(chuàng)建一個(gè)修復(fù)分支，修復(fù)工作完成后，一樣要按照上游優(yōu)選的原則，先合并到 master 分支，經(jīng)過測試才能夠合并到 release 分支，并且此時(shí)要更新小版本號。

小結(jié)

優(yōu)點(diǎn)：

1. 可以區(qū)分不同的環(huán)境部署。
2. 對持續(xù)交付和持續(xù)集成友好。

缺點(diǎn)：

1. 分支多，流程管理復(fù)雜。

TrunkBased

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

使用主干開發(fā)后，只有一個(gè) master 分支了，所有新功能也都提交到 master 分支上，保證每次提交后 master 分支都是可隨時(shí)發(fā)布的狀態(tài)。

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

• 如何避免發(fā)布的時(shí)候引入未完成的 feature
• 如何進(jìn)行線上 bug fix

如何避免發(fā)布的時(shí)候引入未完成的 feature

答案是：Feature Toggle。

既然代碼要隨時(shí)保持可發(fā)布，而我們又需要只有一份代碼來支持持續(xù)集成，在代碼庫里加一個(gè)特性開關(guān)來隨時(shí)打開和關(guān)閉新特性是最容易想到的，當(dāng)然也是最容易被質(zhì)疑的解決方案。

Feature Toggle 是有成本的，不管是在加 Toggle 的時(shí)候的代碼設(shè)計(jì)，還是在移除 Toggle 時(shí)的人力成本和風(fēng)險(xiǎn)，都是需要和它帶來的價(jià)值進(jìn)行衡量的。

事實(shí)上，在我們做一個(gè)前端的大特性變更的時(shí)候，我們確實(shí)因?yàn)闆]辦法 Toggle 而采用了一個(gè)獨(dú)立的 feature 分支，我們認(rèn)為即使為了這個(gè)分支單獨(dú)做一套 Pipeline，也比在前端的各種樣式間添加移除 Toggle 來得簡單。

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

如何進(jìn)行線上 bug fix

在發(fā)布時(shí)打上 release tag，一旦發(fā)現(xiàn)這個(gè)版本有問題，如果這個(gè)時(shí)候 master 分支上沒有其他提交，可以直接在 master 分支上 hot fix，如果 master 分支已經(jīng)有了提交就要做以下四件事：

1. 從 release tag 創(chuàng)建發(fā)布分支。
2. 在 master 上做 bug fix 提交。
3. 將 bug fix 提交 cherry-pick 到 release 分支。
4. 在 release 分支再做一次發(fā)布。

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

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

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

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

總結(jié)

以上四種就是目前相對主流的分支管理策略，但沒有哪一種策略是萬能的。所以無論選擇哪一種，都需要考慮團(tuán)隊(duì)的實(shí)際情況，以及項(xiàng)目的具體業(yè)務(wù)需求，適合自己的才是最好的。

最后，再分享三點(diǎn)小建議：

1. 臨時(shí)分支不應(yīng)該存在太久，每個(gè)分支應(yīng)盡量保持精簡，用完即刪
2. 工作流應(yīng)該盡量簡單，同時(shí)方便回滾
3. 工作流程應(yīng)該符合我們的項(xiàng)目發(fā)布計(jì)劃

以上就是本文的全部內(nèi)容，如果覺得還不錯(cuò)的話歡迎點(diǎn)贊，轉(zhuǎn)發(fā)和關(guān)注，感謝支持。

參考文章：

• Git 分支管理策略與工作流程
• Git 分支管理策略總結(jié)
• 一個(gè)完美的 Git 分支管理模型
• Git 工作流程
• Git 分支管理策略
• 分支模型與主干開發(fā)

擴(kuò)展閱讀：

• 在阿里，我們?nèi)绾喂芾泶a分支？
• 谷歌的代碼管理

推薦閱讀：

• Go 學(xué)習(xí)路線（2022）
• Python 學(xué)習(xí)路線（2022）
• 本著什么原則，才能寫出優(yōu)秀的代碼？