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