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/
雷鋒網雷鋒網雷鋒網
閱讀更多 雷鋒網 的文章
