項(xiàng)目上總有那么多不盡人意的地方，導(dǎo)致各方面出現(xiàn)問題。分支管理策略就是其中一個經(jīng)常遇到的問題。例如：

(1) 主干開發(fā)，發(fā)現(xiàn)代碼質(zhì)量不強(qiáng)，導(dǎo)致代碼提交后阻塞，等待修復(fù)問題。
(2)QA 進(jìn)入了在 Dev 環(huán)境對應(yīng) Master 分支，由于 Dev 環(huán)境一直在合并代碼，QA不得不停下來，因?yàn)榉?wù)有一段時間可能持續(xù)在部署。

上述問題就會讓我們思考應(yīng)該如何讓我們的分支管理對團(tuán)隊(duì)更加有效。

在常見的分支策略上，有的分支策略是指看上去挺有幫助，但是實(shí)際操作過程中并不利于團(tuán)隊(duì)提升效率和改進(jìn)。

常見的三種分支策略：Git Flow、Github Flow、TBD。對于三種常用的分支策略，可以按照下面的思路進(jìn)行選擇。

1, Git Flow

Git Flow 并不是Git上的最佳實(shí)踐。 雖然 Git Flow 是基于 Git 功能構(gòu)建的軟件開發(fā)工作流。

Git Flow 模型是什么？

Git Flow 讓開發(fā)過程基于不同的分支。

Master Branch: Master 分支上的代碼可以隨時部署到 Master 上。

Feature Branch: 每個特性在一個單獨(dú)的 Feature 分支上進(jìn)行開發(fā)，開發(fā)完成后 merge 到 develop branch 上進(jìn)行集成。

Develop Branch: 用來集成的分支，當(dāng)功能達(dá)到穩(wěn)定后，可以 merge 到 master 分支

Release Branch: 為每次發(fā)布準(zhǔn)備 realse 版本，在這個分支上，只進(jìn)行Bug Fix，并在完成后 merge 回到 master 和 develop 分支。

Hotfix Branch: 用于快速修復(fù)，在修復(fù)完成后merge 到 master 和 develop 分支上。

通過這些分支 Git Flow 制定了一套開發(fā)、集成、部署的流程。看上去很好，不同的分支擔(dān)任不同的責(zé)任。但是時間中它的不好確實(shí)超過的它的好。

那么它的問題在哪里呢？

（1）開發(fā)一個新的 Feature 就需要創(chuàng)建一個新的 Branch；

（2）當(dāng)看文字是覺得它簡單，但是離開文字之后，很多開發(fā)者并不清楚哪個環(huán)節(jié)應(yīng)該怎么操作；

（3）Feature 分支阻礙了Merge，Merge 代碼總是很痛苦的，因?yàn)楹苋菀壮鲥e，而且較大的一次 Merge 成本會非常高；

（4）Feature 需要開發(fā)完成后才能 merge 到 develop 分支，無法做到持續(xù)集成。

IDE 做了很多改進(jìn)幫助 Dev 降低 Merge 成本。但是對于業(yè)務(wù)邏輯上的 Merge IDE 是無法幫助 Dev 完成的。

在軟件的世界里，如果一件事很痛苦，我們就頻繁的去做它。比如集成很痛苦，我們就持續(xù)集成。Merge 很痛苦我們就頻繁的 Merge。

顯然 Git Flow 這種分支策略沒有辦法讓我們頻繁的 merge。

---

2, Trunk-based Development ( TBD )

采用 TBD 模式開發(fā)的時候主要有兩個分支：

Master Branch：所有 Dev 在 Master 分支上進(jìn)行開發(fā)。

Release Branch：Release 分支，當(dāng)一個解決過去，從 Master 分支拉出 Release 分支。

我們需要的只是多個環(huán)境：DEV、SIT、UAT、PROD。團(tuán)隊(duì)代碼質(zhì)量高，可以可以直接使用上面四個環(huán)境，如果團(tuán)隊(duì)代碼質(zhì)量不高，可以為 QA 準(zhǔn)備一個 Test 環(huán)境。

（1）如果遇到需要創(chuàng)建 Release 但是功能尚未開發(fā)完成怎么辦？

使用 Feature Toggle 功能，控制開邊的避開閉，當(dāng)然使用 Feature Toggle 也是有成本的，除了添加 Toggle，還需要維護(hù)這些 Toggle。

（2）當(dāng)發(fā)現(xiàn) BUG 怎么辦？

當(dāng) Release 分支發(fā)現(xiàn) Bug 的時候，可以直接在 Release 分支上進(jìn)行修改，修改完成后 merge 回到 master；也可以在 master 分支上進(jìn)行修改，修改完成后 cherry-pick 到 Release 分支。

（3）當(dāng) DEV 環(huán)境不穩(wěn)定怎么辦？

臨時做法就是創(chuàng)建一個 Test 環(huán)境，可以選擇定期自動部署到 Test 環(huán)境，也可 QA 根據(jù)需要手動更新 Test 環(huán)境。

根本做法是提升工程質(zhì)量。在項(xiàng)目管理時間上 和 項(xiàng)目技術(shù)時間上需要同時改進(jìn)。可以通過 Check Style + PMD + Jacoco 在 Dev 本地就運(yùn)行測試，測試通過后才可push（PS：使用git hook來限制一下）。同時團(tuán)隊(duì)可以選擇使用 Arch Unit 來守護(hù)架構(gòu)。

當(dāng)然上面技術(shù)的改進(jìn)的前提是團(tuán)隊(duì)需要些測試，否則持續(xù)集成 只能叫做 "人肉持續(xù)集成"。

---

3, Github Flow

Github Flow 是一個成本較高的分支策略。

Github Flow 需要對每一個分支創(chuàng)建一個運(yùn)行環(huán)境，來驗(yàn)證分支的正確性，這就需要 Ops 提供相應(yīng)的環(huán)境才可以。但是它未解決 merge 時的驗(yàn)證提供了保證。

對 Github Flow 感興趣的可以移步到這里：《Github-Flow》。不過我不認(rèn)為它是真正敏捷的工作流，因?yàn)樗墙⒃谝欢l件基礎(chǔ)上的。

所以如果你的團(tuán)隊(duì)是個小型團(tuán)隊(duì)，可以繞過了，如果是個大型團(tuán)隊(duì)，團(tuán)隊(duì)能力又好，說不定這個 Github Flow 會適合你。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的怎么merge分支_实战 Git 分支策略的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。