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

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

Git flow

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

主要分支 (The main branch)

• master
• develop

輔助分支 (Supporting branch)

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

master

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

develop

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

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

創(chuàng)建 develop 分支：

git checkout -b develop master

將 develop 合并到 master：

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

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

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

feature

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

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

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

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

git checkout -b feature-x develop

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

git checkout develop

git merge --no-ff feature-x

刪除 feature 分支：

git branch -d feature-x

release

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

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

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

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

git checkout -b release-1.2 develop

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

git checkout master

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

再合并到 develop 分支：

git checkout develop

git 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。這時就需要創(chuàng)建一個分支，進行 bug 修復(fù)。

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

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

git checkout -b hotfix-0.1 master

修復(fù)結(jié)束后，合并到 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

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

git branch -d hotfix-0.1

小結(jié)

優(yōu)點：

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

缺點：

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

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

無法持續(xù)交付：Git flow 更傾向于按計劃發(fā)布，一個 feature 要經(jīng)歷很多步驟才能發(fā)布到正式環(huán)境，難以達到持續(xù)交付的要求。

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

Github flow

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

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

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

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

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

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

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

小結(jié)：

優(yōu)點：

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

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

缺點：

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

Gitlab flow

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

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

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

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

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

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

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

開發(fā)分支 master 用于發(fā)布到測試環(huán)境，該分支為受保護的分支。

預(yù)發(fā)分支 pre-production 用于發(fā)布到預(yù)發(fā)環(huán)境，上游分支為 master。

正式分支 production 用于發(fā)布到正式環(huán)境，上游分支為 pre-production。

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

版本發(fā)布

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

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

小結(jié)

優(yōu)點：

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

缺點：

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

TrunkBased

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

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

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

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

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

答案是：Feature Toggle。

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

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

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

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

如何進行線上 bug fix

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

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

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

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

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

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

總結(jié)

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

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

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