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

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

Git flow

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

主要分支 (The main branch)

• master
• develop

輔助分支 (Supporting branch)

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

master

首先，代碼庫(kù)應(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ā)布版本號(hào)的 tag。

創(chuàng)建 develop 分支：

git checkout -b develop master

將 develop 合并到 master：

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

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

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

feature

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

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

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

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

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ā)布正式版本之前，我們可能需要有一個(gè)預(yù)發(fā)布的版本測(cè)試，并且可以在上面做一些較小 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 master

git merge --no-ff release-1.2
# 對(duì)合并生成的新節(jié)點(diǎn)，做一個(gè)標(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ā)布以后，難免會(huì)出現(xiàn) bug。這時(shí)就需要?jiǎng)?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 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)點(diǎn)：

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

缺點(diǎn)：

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

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

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

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

Github flow

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

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

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

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

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

Pull Request 既是一個(gè)通知，讓別人注意到你的請(qǐng)求，又是一種對(duì)話機(jī)制，大家一起評(píng)審和討論你的代碼。對(duì)話過程中，你還可以不斷提交代碼。

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

小結(jié)：

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

降低了分支管理復(fù)雜度，更適合小型團(tuán)隊(duì)，或者維護(hù)單個(gè)版本的項(xiàng)目開發(fā)。

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

缺點(diǎn)：

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

Gitlab flow

它是 Git flow 與 Github flow 的綜合。吸取了兩者的優(yōu)點(diǎn)，既有適應(yīng)不同開發(fā)環(huán)境的彈性，又有單一主分支的簡(jiǎ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ā)布

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

開發(fā)分支 master 用于發(fā)布到測(cè)試環(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)過測(cè)試，再繼續(xù)往 pre-production 合并，要經(jīng)過測(cè)試沒有問題了才能夠再往下合并到生產(chǎn)環(huán)境。

版本發(fā)布

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

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

小結(jié)

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

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

缺點(diǎn)：

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

TrunkBased

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

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

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

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

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

答案是：Feature Toggle。

既然代碼要隨時(shí)保持可發(fā)布，而我們又需要只有一份代碼來支持持續(xù)集成，在代碼庫(kù)里加一個(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 來得簡(jiǎn)單。

但同時(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)有了提交就要做以下四件事：

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

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

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

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

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

總結(jié)

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

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

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