寫在前面
十年前，一篇名為《一個成功的 Git 分支模型》的文章將 Git Flow 推上了風口浪尖。在過去的十年裡，無數個開發團隊被這篇文章矇在鼓裡。說得嚴重一點，他們都被騙了。
文章的作者宣稱他們已經成功地將 Git Flow 引入到項目中，但對於如何在項目中取得成功的細節卻隻字未提。
如果我們盲目地相信這篇文章所說的內容，那無疑是一個巨大的錯誤。我們必須承認，並不是所有的策略都適用於所有的情況、所有的人、所有的環境，而這個道理對於這個分支模型同樣適用。
為了更有說服裡一點，讓我們來更深入地探究一下為什麼我們應該讓 Git Flow 分支模型葬身火海。
Git Flow 太複雜了
Git Flow 太複雜了，看看下面這張圖，它已經很直觀地說明了這一點：
這裡有功能分支、發佈分支、主幹、開發分支、緊急修復分支和標籤。在構建和發佈過程中，你必須跟蹤這些東西，還得理解它們，記得它們。
不僅如此，你還需要從頭到尾跟蹤哪個分支是用來幹什麼的，這對於你來說是一個很重的認知負擔。我已經使用 Git 十年了，我甚至都不確定自己的腦力是否能夠承擔得了這些東西。
Git Flow 違背了分支的“短命”原則
在使用 Git 時，在同一個分支上開發代碼的人越多，出現合併衝突的幾率就越高。在使用 Git Flow 後，衝突幾率會變得更高，因為還有三個其他的分支（具有不同的生命週期）會合併到開發分支上：功能分支、發佈分支和緊急修復分支。現在，出現合併衝突的可能性不是線性的，而是呈三倍的數量增長。
雖然我不願意說“擔心出現合併衝突”是不想採用 Git Flow 分支策略的原因，但當所有這些分支聚集在一起，它們所引入的潛在複雜性是我們無法忽視的。如果你所在的企業提交代碼的速度比較慢，或許沒什麼問題，但對於需要快速開發的企業或初創公司來說，情況就不一樣了。
Git Flow 拋棄了 rebase
如果你要使用 Git Flow，就得放棄 rebase。rebase 取消了合併提交——也就是可以看到兩個分支合併的地方。由於 Git Flow 的複雜性，你需要可視化跟蹤分支，這意味著如果你想要看到來龍去脈，就不能使用 rebase。
Git Flow 阻礙了持續交付
持續交付是指開發團隊的每次代碼提交都會以自動化的方式（在實際當中是與主幹合併）直接發佈到生產環境中。看看這一團糟的 Git Flow，你倒是說說如何能夠進行持續交付？
Git Flow 分支模型是基於可預測的長期發佈週期，而不是基於每隔幾分鐘或幾小時就要發佈新代碼的場景。這種發佈方式的開銷太大了。另外，持續交付的一個核心實踐是通過修復的方式進行發佈，而 Git Flow 將緊急修復作為一個單獨的實體，並與其他開發工作分開。
Git Flow 無法應對多代碼庫
隨著微服務的崛起，小型代碼庫的想法也得到了更多的推動。個體開發團隊可以控制他們的代碼庫和工作流，他們可以控制誰能夠向他們的代碼庫提交代碼以及他們的工作流如何工作。
你有沒有嘗試過使用像 Git Flow 這樣的分支模型，並希望每個人都能達成一致？這是不可能的。很快，系統就會出現不同版本的代碼庫，唯一知道一切的人是使用 YAML 來更新清單的人。你一不小心就很難知道“生產環境中究竟包含了哪些東西”。
Git Flow 無法應對大型單代碼庫
如果因為版本發佈協調困難而無法使用多個微代碼庫，那為什麼不使用一個單獨的大型分支工作流，讓所有的微服務團隊都使用這個工作流？
這種方式在一小段時間內或許是可以的，直到一個開發團隊要發佈版本而其他團隊還沒有準備好。如果開發團隊是獨立的，微服務也是獨立部署的，那就不能將你的工作流很好地與這種分支模型結合在一起。
誰應該（或不應該）使用 Git Flow？
如果你所在的公司採用了月度或季度發佈週期，並且由一個團隊負責並行開發多個項目，那麼 Git Flow 可能是一個不錯的選擇。如果你所在的公司是一個初創公司，或者開發的是一個網站或 Web 應用程序，在一天內可能需要發佈多個版本，那麼使用 Git Flow 對你來說沒有什麼好處。如果你的團隊規模很小（10 人以下），Git Flow 會給你的帶來太多冗繁的工作。
但如果你的團隊有 20 多人並行開發多個版本，那麼使用 Git Flow 可以確保你們不會把事情搞砸。
如果不使用 Git Flow，那應該用什麼？
這個問題我回答不了。並不是所有的分支模型都適用於所有的團隊、所有的環境和所有的文化。如果你採用了持續交付，你會想要一些能夠儘可能簡化交付過程的東西。有些人喜歡基於主幹的開發模式，喜歡使用特性標誌。然而，從測試的角度來看，這些反而會把我嚇一跳。
關鍵在於你要問你的團隊：這種分支模型可以幫助你們解決哪些問題？它會帶來哪些問題？這種模式為哪種開發提供更好的支持？你們想要鼓勵這種行為嗎？你選擇的分支模型最終都是為了讓人們更容易地進行軟件協作開發，因此，分支模型需要考慮到使用者的需求，而不是盲目聽信某些人在網上所聲稱的“成功的分支模型”。
關注我並轉發此篇文章，私信我“領取資料”，即可免費獲得InfoQ價值4999元迷你書！
閱讀更多 InfoQ 的文章
