隨著產品或專案越來越壯大，大部分的團隊也會開始思考透過改善團隊的開發流程，提升產品的品質，例如，在原始碼的品質管理上，開始導入單元測試、整合測試、提倡持續整合、持續部署等機制，而這些機制的背後，通常會有一套屬於版本控制系統的流程管理。

接下來的幾篇，主要會以 GIT 目前常見的幾個開發流程：GitFlow、GitHub Flow、GitLab Flow為主要的討論對象，這些流程，不見得是絕對適用所有場合，但都有一些優點可以討論，今天的這篇，首先就以 GitFlow 當開始。

關於 GitFlow 的起源：

第一次知道到 GitFlow 是在網路上，看到有人討論 nvie 所撰寫的「A successful Git branching model」，他提出了一個如下圖的 GIT 流程線圖管理，這個流程圖，區分為 master、develop、feature、release、master等五個常見的分支，今天主要就是以這張圖，用我自己的說法：

develop 及 master：GitFlow 上一定存在的兩個分支

在 GitFlow 的流程裡，一定存在兩個主要分支，首先是 master 分支，主要是記錄正式版本的原始碼，當標註版本 tag 也是在 master 分支上。develop 分支，剛開始 develop 分支是來自 master 分支，而後只有在預備要釋出正式版本時，develop 分支上的版本，才會透過後面回提到的 release 流程，合併到 master 分支上。

develop 分支：由 develop 建立，回到 develop 分支

所有的新功能特徵，一律由最近的 develop 分支建立新的 feature 分支，而後回到 develop 分支。

feature 分支回到 develop 分支的過程，通常會搭配 Code Review、持續整合(CI)等機制，除了必須要通過人員的 Code Review，也要確認程式碼的測試有通過，才能夠正式合併到 develop 分支上。

在 feature 回 develop 分支的這過程，實務上，也有一些公司會要求，在回到 develop 分支之前，必須先對 origin/develop 作 rebase，才允許回到 develop 分支，這樣產生的線圖會類似如下。相關 git merge 所產生的線圖差異，可以參考 Day 21 所提到的，如何讓線圖更整齊好閱讀。

release 分支：由 develop 建立，合併到 master 及 develop 分支

在原始碼開發到一定的段落之後，系統預備進行 release 的作業，此時會由 develop 分支上建立 release 分支，之後通常會在 release 分支上進行更完善的原始碼測試、修正預備釋出版本等動作，等到確定可以釋出時，會分別將該 release 版本合併到 master 分支以及建立 release 後的修正，合併回到 develop 分支。

合併動作完成後，也會在 master 分支上建立對應的 release tag。

hotfix 分支：由 master 分支建立，合併回 master 及 develop 分支

當線上的主要版本出現必須要馬上解決的問題，這時候會透過 hotfix 機制，開始進行修正。首先會基於 master 分支，建立 hotfix 分支，在該分支上進行問題的修正，當修正完畢之後，會將該修正合併到 master 及 develop 分支上。

為什麼需要合併回 develop 分支呢？因為 hotfix 分支，一開始是基於 master 分支所建立的緊急修正，因此合併回 master 很自然，但因為 hotfix 源自master 分支，自然在目前的 develop 分支上也沒有相關的修正，所以也要合回 develop。

合併動作完成後，也會在 master 分支上建立對應的 release tag。

完整版 GitFlow 流程圖概略如下：

總結：

目前 GitFlow 這個流程最常讓人詬病的是，過程有太多的分支需要建立，流程相對複雜，且對於 GIT 使用還不夠熟悉的使用者來說，這樣的流程需要的 GIT 熟悉程度相對的高，相對的容易在使用的過程中造成一些操作錯誤。

參考連結：

• A successful Git branching model
• git-flow 備忘清單