Git工作流模式選型問題探討
Git工作流
Gitflow模式
特點：使用發布分支、特性分支、bug 修復分支以及預發布分支。主要分支包括 master、develop、feature、release、hotfix。
由于Gitflow模式涉及到了很多不同的分支名稱，所以這里我打算用一系列的圖來和大家介紹下這些分支的概念。
master/feature/develop 分支
首先我們的master分支一定是最終發布上線使用的分支代碼，所有的需求開發，都需要通過master分支中去checkout出來，生成對應的feature分支。
當同一個項目涉及到多個分支改動的時候，就難免會需要進行分支合并后再發布到開發環境的情況發生。
這時候可以通過利用新增一條develop分支的做法，將同一個項目的多條feature分支進行merge后，再發布到開發環境中。如下圖所示：
圖片
采用新增develop分支的模式可以解決開發環境多分支合并部署的問題了。那么release分支又是做什么的呢？
release 分支
開發環境一般主要是給開發調試程序時候使用的，而如果要從開發狀態轉變為測試狀態的話，需要的是一個能夠長期保障穩定性和邏輯順暢性的代碼環境，這個時候建議可以通過新增一套release分支來進行測試環境的代碼管理。如下圖所示：
圖片
從圖中可以看到，不同開發負責的feature分支，在進行提測的時候都需要往相同的release分支進行合并。
當release分支上的代碼通過測試回歸之后，我們可以視作此時的release分支的代碼是屬于可合并到master的狀態。因此一般這個時候會將release分支的代碼分別合并到master和develop分支上，以此來保證準確性。同時此時可以將master分支的代碼發布到預發環境進行最后的回歸驗證。
hotfix分支
其實hotfix分支在使用上可以說和feature分支基本一樣，它的定位是：對master分支上的bug進行修復。hotfix分支也是需要從master分支中checkout出來，然后進行修改，最后合并到develop/release分支上進行回歸驗證，最后并入到master分支進行發布。在一定程度上，hotfix屬于feature分支的一種特殊類型。
圖片
git-flow模式的痛點
其實用久了git-flow模式后，你會很容易發現，這種模式對于分支的領域劃分是非常清晰的。例如develop分支專門用于開發，release分支專門用于測試，hotfix分支專門用于打補丁。
但是隨著迭代的增加，這些分支的管理是一件比較容易出錯的事情。例如：手誤將feature分支合并到release分支。hotfix分支忘記合并到develop分支等等。release分支包含了太多feature分支代碼，其中部分feature分支延遲上線導致release分支代碼需要移除部分commit后再合并到master分支。
這是我認為的git-flow模式的一大痛點。雖然它強調于對分支的標準化管理，但是實際落地在團隊使用的時候，很多毛病都會體現出來。
Github flow模式
特點：Github flow 是Git flow的簡化版，專門配合"持續發布"。它是 Github.com 使用的工作流程。
步驟
- 拉取最新的代碼：git pull origin master
- 創建新的功能分支：git checkout -b feature-branch master
- 開發功能：在新創建的分支上進行修改、提交和測試
- 合并到master：git checkout master -> git merge feature-branch
- 推送到中央存儲庫：git push origin master
圖片
這種模式比較適合于合作人數較少的場景中進行快速開發和迭代。在實際使用中，團隊leader只需要保障master分支的“干凈”即可。各個團隊成員的特性分支代碼獨立。但是如果是涉及到需要多人合作對同一個項目進行并行開發，需要多次進行代碼合并的話，這種開發模式就很痛苦。
Gitlab flow 模式
采用Github flow模式雖然說很靈活，但是它有個強制的要求就是master分支的代碼一定要和生產環境的代碼對齊。
但是在一些特殊的應用場景中，例如IOS開發（需要有審核時間），某些SAAS平臺的一些特殊功能開發，在那類場景中經常是會出現代碼合并到master，但是需要延遲一段時間才發布到生產環境。
Gitlab flow模式就是在上述的Github flow模式中進行的衍生，增加了一個所謂的pre-production分支，用于作為待發布狀態的環境分支，它的代碼合并流程如下所示：
圖片
處于pre-production分支的代碼是經過驗證可以合并到生產環境的代碼，而production分支的代碼則是生產正在運行中的代碼。這個由pre-production到production分支的合并動作，需要由CICD平臺自動化來實現。
說實話，我在實際工作中主要還是用的Github flow模式，Gitlab flow模式個人接觸得并不多。
我的看法
早些年工作的時候，經歷過一些多人合作修改同一個項目的開發工作。那會團隊采用的是git flow的工作流，當時總是會出現合并沖突，分支錯亂，git命令使用錯誤導致代碼丟失等問題。
但是隨著這些年微服務的普及，很多公司其實都已經陸續意識到了大單體架構的痛點，于是也按照領域劃分拆解為了多個微服務。
實際上，隨著微服務粒度在不斷降低，每個開發所負責的領域也開始進行了劃分。如果服務劃分合理，其實一個項目基本上主需要一個 主程 （core developer，有些公司習慣叫項目owner）去維護基本就OK了。如果是這種模式下進行代碼開發的話，其實采用經典的 github flow 或者 gitlab flow 模式進行開發即可滿足。
我認為，隨著日后的發展，業內技術的走向一定是將事情由繁化簡。隨著企業內部的CICD技術體系完善，git flow這種笨重的模式也會漸漸被摒棄，github flow/gitlab flow 這種靈活輕便的模式會越來越受人追崇。
對于git工作流模式來說，我認為沒有絕對完美的方案，只能說結合當前所遇到的業務場景來靈活制定，見招拆招。
