導(dǎo)語(yǔ)：或許，Git-flow 分支模型應(yīng)該葬身火海 。

Git-flow 是一種分支和合并方法。十年前，因?yàn)橐黄麨椤敢粋€(gè)成功的 Git 分支模型」的文章，Git-flow 變得廣為人知。

在過(guò)去的十年里，無(wú)數(shù)團(tuán)隊(duì)被這篇博文蒙在鼓里。但我敢說(shuō)，這篇文章撒謊了。

如果你讀過(guò)這篇博文，你就會(huì)注意到，盡管作者聲稱(chēng)他們?cè)陧?xiàng)目中成功使用了 Git-flow，但卻故意避開(kāi)了讓項(xiàng)目成功的細(xì)節(jié)。

很多人會(huì)相信看到的博文，這其實(shí)是錯(cuò)誤的。并非所有的策略都適用于所有情況，這是一個(gè)真理。我將同樣的邏輯應(yīng)用于這個(gè)分支模型。

好吧，你們當(dāng)中的一些人不相信這個(gè)真理，所以讓我們深入研究為什么 Git-flow 分支模型應(yīng)該葬身火海。

Git-flow 的界面很復(fù)雜

Git-flow 特別復(fù)雜，甚至在考慮微服務(wù)或連續(xù)交付之前就已經(jīng)如此了。下面的圖片直觀地展示了這一點(diǎn)：

圖片來(lái)源：https://nvie.com/posts/a-successful-git-branching-model/

這里有特性分支、發(fā)布分支、master 分支、dev 分支、一個(gè)緊急修復(fù)分支和 git 標(biāo)記。這些都是在構(gòu)建和發(fā)布過(guò)程中必須跟蹤、理解和考慮的事情。

更重要的是，你還需要隨時(shí)跟蹤每個(gè)分支，這造成了很高的認(rèn)知負(fù)荷。我已經(jīng)使用 git 10 年了，我甚至不確定自己是否能在精神上跟上這里的發(fā)展。

Git-flow 違反了「短命」分支規(guī)則

在 git 中，隨著在某個(gè)分支上工作人數(shù)的增加，發(fā)生合并沖突的次數(shù)將大大增加。在 Git-flow 中，這個(gè)數(shù)字增加得更多，因?yàn)檫€有三個(gè)具有不同生命周期的其他分支合并到開(kāi)發(fā)中：特性分支、發(fā)布分支和緊急修復(fù)。合并沖突發(fā)生的可能性并不是線(xiàn)性變化的，它可能會(huì)使合并沖突的概率增加三倍。

這太糟糕了。

雖然我不敢說(shuō)不采用 Git-flow 這樣的分支策略就可以避免合并沖突，但是當(dāng)所有這些分支組合在一起時(shí)，引入的潛在復(fù)雜性太大了，無(wú)法忽略。如果你們公司的代碼提交速度很慢，那就沒(méi)關(guān)系。但是對(duì)于任何快速迭代的組織或初創(chuàng)企業(yè)來(lái)說(shuō)，情況并非如此。

Git-flow 放棄了rebase

重新定位合并節(jié)點(diǎn)是一個(gè)復(fù)雜的話(huà)題，但它很重要。如果你使用 Git-flow，你將不得不放棄 rebase。記住，rebase 取消了合并提交，你再也看不到兩個(gè)分支組合在一起的節(jié)點(diǎn)。由于 Git-flow 的視覺(jué)復(fù)雜性，你需要可視化地跟蹤分支，這意味著如果你想解決問(wèn)題，就不需要 rebase。

Git-flow 使連續(xù)交付變得不可能

持續(xù)交付是一種實(shí)踐。在這種實(shí)踐中，團(tuán)隊(duì)以自動(dòng)化的方式直接發(fā)布到生產(chǎn)中（實(shí)際上是合并到 master）。看看混亂的 Git-flow，你能解釋一下如何持續(xù)地交付嗎？

整個(gè)分支模型是根據(jù)可預(yù)測(cè)的、長(zhǎng)期的發(fā)布周期進(jìn)行預(yù)測(cè)的。如果每隔幾分鐘或幾小時(shí)發(fā)布一次新代碼，開(kāi)銷(xiāo)就太大了，更不用說(shuō) CD 的中心實(shí)踐之一是向前滾動(dòng)修復(fù)。Git-flow將修補(bǔ)程序視為一個(gè)單獨(dú)的實(shí)體，需要小心地控制，并與其他工作分離開(kāi)來(lái)。

在多個(gè)存儲(chǔ)庫(kù)中不可能使用 Git-flow

隨著微服務(wù)的出現(xiàn)，micro-repo 的理念也得到了更多的推動(dòng)，各個(gè)團(tuán)隊(duì)可以控制他們的存儲(chǔ)庫(kù)和工作流，他們還可以控制誰(shuí)進(jìn)入了他們的存儲(chǔ)庫(kù)以及其工作流是如何工作的。

你有沒(méi)有嘗試過(guò)這樣一個(gè)復(fù)雜的分支模型：它有多個(gè)團(tuán)隊(duì)，并且希望它們都在同一個(gè)頁(yè)面上？這是不會(huì)發(fā)生的。很快，這個(gè)系統(tǒng)就變成了不同 repo 的不同版本的一個(gè)清單，只有敲出 YAML 來(lái)更新清單的人知道所有東西在哪里。如果你不夠細(xì)心，「在生產(chǎn)什么」就變成了一個(gè)存在主義的問(wèn)題。

Git-flow 也不可能在 monorep 中使用

因此，如果由于協(xié)調(diào)發(fā)布的困難而取消了 micro-repo，那為什么不讓所有微服務(wù)團(tuán)隊(duì)都遵守一個(gè)大的發(fā)布分支工作流呢？

這個(gè)過(guò)程大約持續(xù) 3.2 秒。如果團(tuán)隊(duì)是獨(dú)立的，micro-repo 應(yīng)該是獨(dú)立部署的，這樣就不能很好地將你的工作流程與你在 mono repo 中創(chuàng)建的集中式分支模型聯(lián)系起來(lái)。

誰(shuí)應(yīng)該/不應(yīng)該使用 Git-flow？

如果你的團(tuán)隊(duì)每月或每季度發(fā)布一次，并且是一個(gè)并行處理多個(gè)發(fā)布的團(tuán)隊(duì)，那么 Git-flow 可能是一個(gè)不錯(cuò)的選擇。如果你的團(tuán)隊(duì)是一個(gè)初創(chuàng)企業(yè)，或者是一個(gè)面向 internet 的網(wǎng)站或 web 應(yīng)用程序，同一天可能發(fā)布多個(gè)版本，那 Git-flow 對(duì)你來(lái)說(shuō)就不合適了。如果你的團(tuán)隊(duì)是一個(gè)不到 10 人的微型團(tuán)隊(duì)，Git-flow 會(huì)給你的工作帶來(lái)太多的規(guī)矩和開(kāi)銷(xiāo)。

另一方面，如果你的團(tuán)隊(duì)有 20 多人進(jìn)行并行發(fā)布，那么 Gitflow 可以確保不會(huì)把事情搞砸。

如果不應(yīng)該使用 Git-flow，那應(yīng)該用什么？

我不能回答。并非所有分支模型都適用于所有團(tuán)隊(duì)和所有情況。如果你練習(xí) CD，你需要一些盡可能簡(jiǎn)化過(guò)程的東西。

關(guān)鍵在于，團(tuán)隊(duì)需要反思：這個(gè)分支模型將幫助我們解決哪些問(wèn)題？會(huì)產(chǎn)生什么問(wèn)題？這種模型將鼓勵(lì)什么樣的發(fā)展？我們想鼓勵(lì)這種行為嗎？使用分支模型的最終目的都是方便軟件開(kāi)發(fā)過(guò)程中的合作，因此，需要考慮使用它的特定人群的需求，而不是互聯(lián)網(wǎng)流傳的「成功」的東西。