Git Flow 是什麼？

2010年5月，在一篇名為“A successful Git branching model”的博文中，原Git Prime的首席技術官Vincent Driessen介紹了一種構建在Git（一個開源的分布式版本控制系統）之上的軟件開發模型。通過利用Git創建和管理分支的能力，為每個分支設定具有特定的含義名稱，并将軟件生命周期中的各類活動歸并到不同的分支上，實現了軟件開發過程不同階段的相互隔離。這種軟件開發的活動模型被Vincent稱為“Git Flow”（Git工作流程）。Git Flow已經開始流行于基于主幹的工作流，它現在被認為是現代連續軟件開發和DevOps（開發、技術運營和質量保障三者的交集）實踐的最佳實踐。

這是Vincent博文中的Git Flow流程圖：（從右向左看，從上到下看）

Git Flow分支說明

Git Flow的核心就是分支(Branch），通過在項目的不同階段對分支的不同操作（包括但不限于創建、合并、變基等）來實現一個完整的高效率的工作流程。Git Flow的分支主要分為兩大類：主分支和輔助分支。其中主分支包含主要分支和開發分支，而輔助分支包含功能分支、預發分支、熱修複分支以及其他自定義分支。

1，主要分支（Master）

主要分支上存放的是最穩定的正式版本，并且該分支的代碼應該是随時可在生産環境中使用的代碼。當一個版本開發完畢後，産生了一份新的穩定的可供發布的代碼時，主要分支上的代碼要被更新。同時，每一次更新，都需要在主要分支上打上對應的版本号。

任何人不允許在主要分支上進行代碼的直接提交，隻接受其他分支的合入。原則上主要分支上的代碼必須是合并自經過多輪測試及已經發布一段時間且線上穩定的預發分支。

2、開發分支（Develop）

開發分支是主開發分支，其上更新的代碼始終反映着下一個發布版本需要交付的新功能。當開發分支到達一個穩定的點并準備好發布時，應該從該點拉取一個預發分支并附上發布版本号。也有人稱開發分支為集成分支，因為會基于該分支和持續集成工具做自動化的構建。

開發分支接受其他輔助分支的合入，最常見的就是功能分支，開發一個新功能時拉取新的功能分支，開發完成後再并入開發分支。需要注意的是，合入開發的分支必須保證功能完整，不影響開發分支的正常運行。

3、功能分支（Feature）

功能分支一般命名為 Feature/xxx，用于開發即将發布版本或未來版本的新功能或者探索新功能。該分支通常存在于開發人員的本地代碼庫而不要求提交到遠程代碼庫上，除非幾個人合作在同一個功能分支開發。關于這點，Thought Works洞見上有一篇文章“Git Flow有害論”做了非常有意思的闡述，文章下的評論也異常激烈。也許該文章的名字可能有失偏頗，但文章的本意以及評論傳達了一個觀點：功能分支要求足夠細粒度以避免成為長期存在的功能分支，應當小步合并而不是一次合并大量代碼。

功能分支隻能拉取自開發分支，開發完成後要麼合并回開發分支，要麼因為新功能的嘗試不如人意而直接丢棄。

4、預發分支（Release）

預發分支一般命名為 Release/1.2（後面是版本号），該分支專為測試—發布新的版本而開辟，允許做小量級的Bug修複和準備發布版本的元數據信息（版本号、編譯時間等）。通過創建預發分支，使得開發分支得以空閑出來接受下一個版本的新的功能分支的合入。

預發分支需要提交到服務器上，交由測試工程師進行測試，并由開發工程師修複Bug。同時根據該分支的特性我們可以部署自動化測試以及生産環境代碼的自動化更新和部署。

預發分支隻能拉取自開發分支，合并回開發分支和主要分支。

5、熱修複分支（Hotfix）

熱修複分支一般命名為Hotfix/1.2.1（後面是版本号），當生産環境的代碼（主要分支上代碼）遇到嚴重到必須立即修複的缺陷時，就需要從主要分支上指定的tag版本（比如1.2）拉取熱修複分支進行代碼的緊急修複，并附上版本号（比如1.2.1）。這樣做的好處是不會打斷正在進行的開發分支的開發工作，能夠讓團隊中負責功能開發的人與負責修複的人并行、獨立的開展工作。

熱修複分支隻能主要分支上拉取，測試通過後合并回主要分支和開發分支。

Git Flow模型通過不同的分支從源代碼管理的角度對軟件開發活動進行了約束，為我們的軟件開發提供了一個可供參考的管理模型。Git Flow模型讓代碼倉庫保持整潔，讓小組各個成員之間的開發相互隔離，能夠有效避免處于開發狀态中的代碼相互影響而導緻的效率低下和混亂。但同時，不同的開發團隊存在不同的文化，在不同的項目背景情況下都可能根據該模型進行适當的精簡或擴充。防控中心通過合理使用Git Flow，更好地管理代碼倉庫，提高工作的效率。

本文内容為原創，轉載請注明出處！

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!