導語：或許，Git-flow 分支模型應該葬身火海 。

Git-flow 是一種分支和合并方法。十年前，因為一篇名為「一個成功的 Git 分支模型」的文章，Git-flow 變得廣為人知。

在過去的十年里，無數(shù)團隊被這篇博文蒙在鼓里。但我敢說，這篇文章撒謊了。

如果你讀過這篇博文，你就會注意到，盡管作者聲稱他們在項目中成功使用了 Git-flow，但卻故意避開了讓項目成功的細節(jié)。

很多人會相信看到的博文，這其實是錯誤的。并非所有的策略都適用于所有情況，這是一個真理。我將同樣的邏輯應用于這個分支模型。

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

Git-flow 的界面很復雜

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

圖片來源：https://nvie.com/posts/a-successful-git-branching-model/

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

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

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

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

這太糟糕了。

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

Git-flow 放棄了rebase

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

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

持續(xù)交付是一種實踐。在這種實踐中，團隊以自動化的方式直接發(fā)布到生產(chǎn)中（實際上是合并到 master）?？纯椿靵y的 Git-flow，你能解釋一下如何持續(xù)地交付嗎？

整個分支模型是根據(jù)可預測的、長期的發(fā)布周期進行預測的。如果每隔幾分鐘或幾小時發(fā)布一次新代碼，開銷就太大了，更不用說 CD 的中心實踐之一是向前滾動修復。Git-flow將修補程序視為一個單獨的實體，需要小心地控制，并與其他工作分離開來。

在多個存儲庫中不可能使用 Git-flow

隨著微服務的出現(xiàn)，micro-repo 的理念也得到了更多的推動，各個團隊可以控制他們的存儲庫和工作流，他們還可以控制誰進入了他們的存儲庫以及其工作流是如何工作的。

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

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

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

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

誰應該/不應該使用 Git-flow？

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

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

如果不應該使用 Git-flow，那應該用什么？

我不能回答。并非所有分支模型都適用于所有團隊和所有情況。如果你練習 CD，你需要一些盡可能簡化過程的東西。

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