Git-flow作者稱其不適用於持續交付?

「本文已參與好文召集令活動，點選檢視：後端、大前端雙賽道投稿，2萬元獎池等你挑戰！」

前言

Git-flow是由Vincent Driessen在2010年提出的一個Git分支模型,在這10年中，Git-flow在許多軟體團隊中變得非常流行，以至於人們開始將其視為某種標準。
不過最近Vincent Driessen更新了他10年前那篇著名的A successful Git branching model，大意是Git-flow已不適用於當今持續交付的軟體工程方式,推薦更簡單的Github flow等模型

連Git-flow作者都承認Git-flow不適合持續交付了，那我們更有必要好好研究一下了，以免掉坑裡。
本文主要包括以下內容：
1.Git-flow介紹
2.為什麼Git-flow不適用於持續交付？
3.Github flow介紹
4.Gitlab flow介紹

1. Git-flow是什麼?

Git-flow是由Vincent Driessen在2010年提出的一個Git分支模型,其結構圖如下所示，相信大家都看過

Git-flow主要包括以下分支

• master 是長期分支，一般用於管理對外發布版本，每個commit對一個tag，也就是一個釋出版本
• develop 是長期分支，一般用於作為日常開發彙總，即開發版的程式碼
• feature 是短期分支，一般用於一個新功能的開發
• hotfix 是短期分支 ，一般用於正式釋出以後，出現bug，需要建立一個分支，進行bug修補。
• release 是短期分支，一般用於釋出正式版本之前（即合併到 master 分支之前），需要對預釋出的版本進行測試。release 分支在經歷測試之後，測試確認驗收，將會被合併到 develop 和 master

1.1 Git-flow工作流程

一般工作流程如下：

• 1.日常在develop開發
• 2.如果有比較大的功能或者其他需求，那麼新開分支：feature/xxx 來做，並在這個分支上進行打包和提測。
• 3.在封版日，將該版本上線的需求合併到develop，然後將開個新的分支release/版本號(如release/1.0.1),將develop合併至該分支。
• 4.灰度階段，在releases/版本號 分支上修復BUG，打包併發布,釋出完成後反合入master與develop分支
• 5.如果在全量釋出後，發現有線上問題，那麼在對應的master分支上新開分支hotfix/{版本號}來修復，並升級版本號，修復完成後，然後將hotfix合併到master，同時將合併到develop

2. 為什麼Git-flow不適用於持續交付？

在這 10 年中，Git 本身已經席捲全球，並且使用 Git 開發的最受歡迎的軟體型別正在更多地轉向 Web 應用程式——至少在我的過濾器氣泡中。 Web 應用程式通常是持續交付的，而不是回滾的，而且您不必支援同時 執行的多個版本的軟體。

如Vincent Driessen所述。Git-flow描述了feature分支、release分支、master或develop分支以及hotfix分支是如何相互關聯的。
這種方法非常適用於使用者下載的打包軟體，例如庫和桌面應用程式。

然而，對於許多Web應用來說，Git-flow是矯枉過正的。有時，您的develop分支和release分支之間沒有足夠大的差異來區分值得。或者，您的hotfix分支和feature分支的工作流程可能相同。
在這種情況下，Vincent Driessen推薦Github flow分支模型

Git-flow的主要優點在於結構清晰，每個分支的任務劃分的很清楚，而它的缺點自然就是有些複雜了
Git-flow需要同時維護兩個長期分支。大多數工具都將master當作預設分支，可是開發是在develop分支進行的，這導致經常要切換分支，非常煩人。
更大問題在於，這個模式是基於"版本釋出"的，目標是一段時間以後產出一個新版本。但是，很多網站專案是"持續釋出"，程式碼一有變動，就部署一次。這時，master分支和develop分支的差別不大，沒必要維護兩個長期分支

2.1 Git-fow何時值得額外的複雜性

當然，是否使用Git-flow取決於你的業務複雜性，有時使用Git-flow是必須的，主要是當你需要同時維護多版本的時候,適合的是需要『多個版本並存』的場景
所謂『多版本並存』，就是說開發團隊要同時維護多個有客戶使用的版本，對於傳統軟體，比如我開發一個新的作業系統叫做Doors，先賣v1，賣出去1000萬份，然後看在v1的基礎上開發v2，但是客戶會持續給v1提bug，這些bug既要在v1的後續補丁中fix，也要在v2中fix，等v2再賣出去2000萬份開始開發v3的時候，v1依然有客戶，我就必須要維持v1、v2、v3三個多版本都要支援。

關於Git-flow同時支援多個版本，很多人可能會有疑問，因為develop只針對一個版本能持續交付
說實話我也感覺挺疑問的，後面查閱資料發現還有一個衍生的support分支，可以同時支援多個版本,在興趣的同學可參考:mindsers.blog/post/severa…

3.Github flow介紹

Github flow它只有一個長期分支，就是master，因此用起來非常簡單。

• 第一步：根據需求，從master拉出新分支，不區分功能分支或補丁分支。
• 第二步：新分支開發完成後，或者需要討論的時候，就向master發起一個pull request（簡稱PR）。
• 第三步：Pull Request既是一個通知，讓別人注意到你的請求，又是一種對話機制，大家一起評審和討論你的程式碼。對話過程中，你還可以不斷提交程式碼
• 第四步：佈署流程：當專案負責人同意新功能可以釋出，且程式碼也通過稽核了。但是在程式碼合併之前還是要進行測試。所以要把feature分支的程式碼部署到測試環境進行測試
• 第五步：你的Pull Request被接受，合併進master，重新部署到生產環境後，原來你拉出來的那個分支就被刪除。
• 第六步：修復正式環境bug流程：從master分支切一個HotFix分支，經過以上同樣的流程發起PR合併即可

3.1 Github flow的優點

Github flow的最大優點就是簡單，對於"持續釋出"的產品，可以說是最合適的流程。

3.2 Github flow的缺點

它的問題也在於它的假設：master分支的更新與產品的釋出是一致的。也就是說，master分支的最新程式碼，預設就是當前的線上程式碼。
可是，有些時候並非如此，程式碼合併進入master分支，並不代表它就能立刻釋出。比如，蘋果商店的APP提交稽核以後，等一段時間才能上架。這時，如果還有新的程式碼提交，master分支就會與剛釋出的版本不一致。另一個例子是，有些公司有釋出視窗，只有指定時間才能釋出，這也會導致線上版本落後於master分支。
上面這種情況，只有master一個主分支就不夠用了。通常，你不得不在master分支以外，另外新建一個production分支跟蹤線上版本。

同時對於Github flow我還有個疑問，合併到master分支後即會部署到生產環境，但是在merge後的程式碼難道不會產生衝突嗎？合併衝突難道不需要重新測試嗎？如果評論區有了解的小夥伴可以解惑下

Github flow用起來比較簡單，但是在很多公司的業務開發過程中一般都有開發、測試、預釋出、生產幾個環境，沒有強有力的工具來支撐，我認為很難用這種簡單的模式來實現管理。
看起來這種模式特別適合小團隊，人少，需求少，比較容易通過這種方式管理分支。

4.Gitlab flow介紹

Gitlab flow 是 Git-flow與Github flow的綜合。它吸取了兩者的優點，既有適應不同開發環境的彈性，又有單一主分支的簡單和便利。它是Gitlab.com推薦的做法。
Gitlab flow的最大原則叫做”上游優先”（upsteam first），即只存在一個主分支master，它是所有其他分支的”上游”。只有上游分支採納的程式碼變化，才能應用到其他分支。
Gitlab flow分為持續釋出與版本釋出兩種情況，以適應不同的釋出型別

4.1 持續釋出

對於”持續釋出”的專案，它建議在master分支以外，再建立不同的環境分支。
比如，”開發環境”的分支是master，”預發環境”的分支是pre-production，”生產環境”的分支是production。

開發分支是預發分支的"上游"，預發分支又是生產分支的"上游"。程式碼的變化，必須由"上游"向"下游"發展。比如，生產環境出現了bug，這時就要新建一個功能分支，先把它合併到master，確認沒有問題，再cherry-pick到pre-production，這一步也沒有問題，才進入production。

只有緊急情況，才允許跳過上游，直接合併到下游分支。

4.2 版本釋出

對於"版本釋出"的專案，建議的做法是每一個穩定版本，都要從master分支拉出一個分支，比如2-3-stable、2-4-stable等等。
以後，只有修補bug，才允許將程式碼合併到這些分支，並且此時要更新小版本號。

4.3 Gitlab flow開發流程

對於Android開發，我們一般使用版本釋出，因此我們使用Gitlab flow開發的工作流為

• 1.新的迭代開始，所有開發人員從主幹master拉個人分支開發特性, 分支命名規範 feature-name
• 2.開發完成後，在迭代結束前，合入master分支
• 3.master分支合併後，自動cicd到dev環境
• 4.開發自測通過後，從master拉取要釋出的分支，release-$version，將這個分支部署到測試環境進行測試
• 5.測出的bug，通過從release-$versio拉出分支進行修復，修復完成後，再合入release-$versio
• 6.正式釋出版本，如果上線後，又有bug，根據5的方式處理
• 7.等釋出版本穩定後，將release-$versio反合入主幹master分支

值得注意的是，按照Github flow規範，第5步如果測出bug,應該在master上修改，然後cherry-pick到releases上來，但是這樣做太麻煩了，直接在releases分支上修復bug然後再反合入master分支應該是一個簡單而且可以接受的做法

總結

正如Vincent Driessen所說的,總而言之，請永遠記住，靈丹妙藥並不存在。考慮你自己的背景。不要討厭。自己決定。

Git-flow適用於大團隊多版本並存迭代的開發流程
Github-flow適用於中小型團隊持續整合的開發流程
Gitlab-flow適用範圍則介於上面二者之間，支援持續釋出與版本釋出兩種情況

總得來說，各種Git工作流自有其適合工作的場景,畢竟軟體工程中沒有銀彈,讀者可根據自己的專案情況對比選擇使用，自己決定~

參考資料

如何看待 Git flow 發明人稱其不適用於持續交付？
Git 開發工作流程：Git Flow 與 GitHub Flow
Git 工作流程
高效團隊的gitlab flow最佳實踐

擴充套件閱讀

一些大廠的Git工作流，有興趣的同學可以瞭解下
在阿里，我們如何管理程式碼分支？
位元組研發設施下的 Git 工作流
簡介我的 Git Work Flow