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

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

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

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

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

　　Git-flow 的界面很復雜

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

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

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

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

　　Git-flow 違反了「短命」分支規則

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

　　這太糟糕了。

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

　　Git-flow 放棄了rebase

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

　　Git-flow 使連續交付變得不可能

　　持續交付是一種實踐。在這種實踐中，團隊以自動化的方式直接發布到生產中（實際上是合并到 master）。看看混亂的 Git-flow，你能解釋一下如何持續地交付嗎？

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

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

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

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

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

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

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

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

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

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

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

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

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

　　via：https://georgestocker.com/2020/03/04/please-stop-recommending-git-flow/

總結

以上是生活随笔為你收集整理的抛弃 Git Flow 的 8 大理由的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。