Git 工做流，知其然知其因此然

時間 2019-11-06

標籤 git 其然因此欄目 Git 简体版

原文原文鏈接

閱讀原文：github.com/ruizhengyun…html

前言

雖然經歷過 svn 年代，工做流程中也用到了 svn，但更多時候仍是在用 git，相信不少開發小夥伴也在用 git 吧，市場上已經有不少關於 git 知識介紹了，那爲何我還要寫一本線上小書呢？坦白說寫下來是爲了手過把癮、這個過程對 git 知識也有了個系統性認知，若是能幫到讀者一二，那最好不過了。git

和別的小書稍稍有個出入，不在給 Git 給予太多文字的簡介，由於你確定多少知道它是什麼東西。github

爲何有分支

其實很簡單，就是來源功能驅動開發（Feature-driven developer，簡稱 FDD），協做開發就得有版本管理，管理的天然就是分支了。編程

功能驅動開發就是：需求來了，如果功能，則創建功能分支（feature branch）；如果 bug，則創建補丁分支（hotfix branch）。完成開發後，該分支就合併到相應主分支，而後刪除，版本發佈後記得打上 git 標籤。svn

工做流

Git 做爲一個源碼管理系統，多人協做才能看到其價值。這和 github 社會化編程相互輝映，成就彼此。既然協做，就得有一個規範化的工做流程，讓你們有效地合做，使得項目層次分明地發展下去。工做流程能夠稱爲 "workflow" 或"flow"，即水流，比喻項目像水流那樣，順暢、天然地向前流動。工具

對於工做流程方式，經常使用 3 種方式測試

Git flow
Github flow
Gitlab flow

Git flow

這個工做流是 Vincent Driessen 2010 年發佈出來的分支管理模型，熱度很是高，我安利的也是這個，公司管理項目也是這麼玩的。優化

按功能劃分，可分爲 5 種分支Master、Develop、Release、Feature 和 Hotfix；
按生命週期劃分，可分爲長期分支和暫時分支，更貼切地說，主要分支和協助分支；

分支	分支名稱	生命週期	描述
Master	主分支	長期	從這個分支上檢出的都是穩定的發佈版，版本發佈後記得打上 git 標籤。好處是，在測試的時候，不影響下一個版本功能並行開發
Hotfix	修復分支	暫時	用於線上緊急 bug 修復，修復後，合併回 Master 和 Develop，而後刪除分支
Release	預發分支	暫時	版本提測後，刪除 Feature，發現 bug，從 Develop 檢出 Release 分支，修改後提交，測試發佈後，合併到 Master 和 Develop，而後刪除分支
Develop	開發分支	長期	用於平常開發，存放最新的開發版，完成一個版本合併到這裏
Feature	功能分支	暫時	用來作分模塊功能開發，本次版本有 5 我的開發就建 5 個分支，完成後合併到 Develop

總結下ui

Master 檢出 Hotfix、Develop 分支，合併 Hotfix、Release 分支，而後打標籤；
Develop 檢出 Feature、Release 分支，合併 Feature、Release、Master 分支；
被合併的分支刪可當即除掉；

Merge

即合併分支，這個階段加上參數 no-ff，即策略合併，這這種方式會多以合併提交，好處是保證一個很是清楚的提交歷史，能夠看到被合併分支的存在，我想這也是分支存在的一塊兒所在。相反，不要選擇默認合併方式 Fast-Forword。spa

怎麼樣，上面流程配色是否很舒服和分支流向是否很清晰？

完美背後的瑕疵

雖然 Git Flow 解決了項目管理的分支管理，但實際使用過程當中，仍是有一些問題：

Hotfix 和 Release 分支在版本快速迭代的項目中，幾乎用不到，剛開發完就直接合併到 Master 發版，出現問題 Develop 分支直接修復發佈下個版本了；
Hotfix 從 Master 檢出，完成後合併到 Master 分支，Release 分支 Develop 檢出，完成後合併到 Master 分支和 Develop 分支，實際項目管理中，不少開發者會忘記合併回 Master 分支和 Develop 分支；

Github flow

最簡單的一種工做流程方式，開源項目就是採用這種方式，含Master + Feature(含 Hotfix)。

Master 主分支
Feature 功能分支（Hotfix 補丁分支，補丁也能夠看作功能）

說明

Master 是惟一分支，永遠是可發佈狀態。通常主分支都設置 protected 分支保護，只有有權限的人才能推送代碼到 Master；
如有新功能（補丁也是一種功能），從 Master 檢出新分支；
本地分支提交代碼，保證按時向遠程倉庫推送；
功能開發完畢，能夠發起一個 pull request（PR），PR 既是一個通知，讓別人注意到你的請求，也是一種對話機制，社會開發人員一塊兒評審和討論你的代碼，這個過程當中可繼續提交代碼;
當 review 或者討論經過後，代碼會合併到目標分支；
一旦合併到 Master，應該當即發佈，從新部署後，你檢出的分支就被刪除；

最大特點

在我看來，Github flow 最大特點就是 PR，這是一個偉大的發明，除了分支合併功能，還有

能夠很好控制分支合併權限；
分支不是你想合併就合併，須要對方贊成；
對於"持續發佈"的產品，再合適不過；
問題討論或尋求其餘小夥伴們的幫助，就和拉個羣差很少，能夠選擇相關的人蔘與，並且參與的人還能夠向你的分支提交代碼，能夠說，是很是適合社會化編程代碼交流。
代碼 Review，若是代碼寫的不友好，有了 pull request 提供的評論功能支持，能夠接受 review 的實時吐槽；

問題追蹤

平常開發中，會用到第三方庫。使用過程當中，出現了問題，第一個反應是去這個第三方庫的 GitHub 倉庫去搜索一下 issue ，看沒有人遇到過，項目維護者修復了沒有，通常未解決的 issue 是 open 狀態，已解決的會被標記爲 closed。這就是問題追蹤 issue tracking（issue 解決效率也是選用第三方庫的一個標準）。

若是你第三方庫（開源項目）的維護者，除了標記 issue 的狀態（open 和 closed），還能夠給它標記上不一樣的標籤，來優化項目。當提交的時候，若是提交信息中有 fix #1 等字段，能夠自動關閉對應編號的 issue。

不得不說問題追蹤很是適合開源項目。Github 社區使用的就是這個工做流模型，能夠建個項目耍耍，拉進直男間的距離，哈哈。

完美背後的瑕疵

GitHub Flow 是簡化了 Git Flow，就一個長期分支 Master，同時提供了圖形界面工具，必定程度上避免了一些問題，但仍是有一些實際問題:

版本的延遲發佈（例如 iOS 應用審覈到經過中間，此時要往 Master 上推送代碼）;
不一樣環境的部署；
不一樣版本發佈與修復，一個 Master 分支不夠用啊（臣妾作不到啊）；

Gitlab flow

年輕的工做流模式。它是 GitLab 的 CEO Sytse Sijbrandij 在 2014 年 9月 29 正式發佈出來的。由於後出現的，因此站在巨人的肩膀上，集兩種方式之長，補其之短。既有適應不一樣開發環境的彈性（分支策略），又有單一主分支的簡單和便利（PR 和 issue tracking）。

版本的延遲發佈

一個 Master 分支不夠，那就添加了一個分支 Prodution，專門用來發布版本。

不一樣環境的部署及上游優先

在 Master 分支以外，再建兩個環境分支：

分支	環境分支	上下游
Master	開發分支	功能分支是開發分支的"上游"
Pre-production	預發分支	開發分支是預發分支的"上游"
Production	生產分支	預發分支又是生產分支的"上游"

Feature -> Master -> Pre-production -> Production
複製代碼

若代碼的變化，必須由"上游"向"下游"發展，即合併順序，按環境依次推送，確保代碼測試過，從上游分支合併到下游分支。緊急狀況下，才容許跳過上游，直接合併到下游分支，即 upstream first，上游優先。

版本發佈分支

對外發布版本的記錄是很是重要的。線上出現了一個問題，須要拿到問題出現對應版本的代碼，才能準肯定位問題。在 Git Flow，版本記錄是經過 Master 上的 Tag 來記錄。發現問題，建立 Hotfix 分支，完成以後合併到 Master 和 Develop。

在 GitLab Flow ，建議的作法是每個穩定版本，都要從 Master 分支拉出一個分支，好比 0-1-0-stable、0-2-0-stable 等等。發現問題，就從對應版本分支建立修復分支，完成以後，先合併到 Master。若此時還有預發佈分支，還要合併到 Release 分支，遵循「上游優先」原則。