以下將敘述 git flow / github flow / gitlab flow
Git Flow
Master 分支
用來放穩定、可上線的版本。這個分支只能從別的分支合併過來，開發者不會直接 Commit 到這個分支。此為穩定版本，因此會在這個分支上的 Commit 上加上版本號標籤(tag)。
Develop 分支
所有開發的基礎分支，當要新增功能時，所有的 Feature 分支都是從這個分支切出去的。而 Feature 分支的功能完成後，也會合併至該分支。
Hotfix 分支
當線上產品發生緊急問題的時候，會從 Master 分支開一個 Hotfix 分支出來進行修復，Hotfix 分支修復完成之後，會合併回 Master 分支，也同時會合併到 Develop 分支。
為什麼要合併回 Develop 分支？若不這麼做，等 Develop 分支完成並且合併回 Master 分支的時候，該問題就會再次出現。
那為何不一開始從 Develop 分支切出來修正？因 Develop 分支的功能可能尚在開發中，這時候從 Develop 切出去修再合併回 Master 分支，必定會造成更大的災情。
Release 分支
當 Develop 分支開發到一定程度，就可以把 Develop 分支合併到 Release 分支，進行上線前的最後測試。測試完成後，Release 分支將會同時合併到 Master 以及 Develop 這兩個分支上。Master 是上線版本，而合併回 Develop 是因為在 Release 上可能還會修正一些問題，所以跟 Develop 同步，以免之後的版本又再出現相同問題。
Feature 分支
當要開始新增功能的時候，就是使用 Feature 分支的時候了。Feature 分支都是從 Develop 分支來的，完成之後會再併回 Develop 分支。
Github Flow
整個 GitHub Flow 是基於分支，它是 Git 的一個核心概念。
有一個規則：任何在 master 分支中的都是可部署的。
正此，當在進行一個功能開發或修復時，分離出新分支與 master 是非常重要的。分支命名應該具有描述性，讓其他人清楚知道分支正在進行的工作項目。
Commits
加入commit的過程讓你可以追蹤分支的工作進度。
Commit 的流程產生了一個透明的工作記錄，讓別人了解你做了些什麼，以及原因。每個 commit 都有相關的訊息，用來解釋修改原因及內容。此外，每個 commit 被視為一個獨立的修改個體。使你在找到錯誤或決定更改開發方向時可以復原修改。
Commit 的訊息是很重要的，當 Git 追蹤修改並顯示相關 commit 於遠端上。透過撰寫清楚的提交訊息，可以更容易讓別人了解並提供回饋。
Pull Request
你能在開發過程任何時間點，開啟一個 Pull Request，例如：你對某個專案有想法想進行修改，先 fork 到自己帳號下，修改完畢後 Push 回自己帳號下的專案，然後通知 ( Pull request ) 請原作者查看，若 commit 內容可以，便會 Merge 回原專案，為該專案貢獻。
Pull Request 對於協作開源專案和管理共享儲存庫非常有用。如果你使用的是 Fork 及 Pull Model，Pull Request 提供了一個方式法來通知專案維護者來考慮使用你的修改。如果使用的是 Shared Repository Model，在合併到 master 之前，Pull Request 會協助檢閱、討論修改建議。
Check and comment code
當 Pull Request 被開啟，檢閱修改的人或維護團隊可能會提出問題或意見。也許是程式碼風格不符合專案規範、缺少單元測試，或一切都 OK。Pull Request 鼓勵這種類型的討論。
在評論你的提交時，你還可以繼續推送（Push）到你的分支。如果有反應說你忘了做某件事，或者在程式碼中有錯誤，你可以在分支中修正它並繼續推送修改。GitHub 會在 Pull Request 頁面顯示你的新提交及任何收到的額外回饋。
Pull request 的評論都是用 Markdown 撰寫，所以你可以插入圖片和表情符號，使用預先格式化的文字區塊，及其他輕量化的格式。
Deploy
Pull 取請求已被檢閱且分支通過測試，你可以部署他在產品中去驗證。假如你的分支產生問題，你可以重新部署 master 來回覆上一動。
Merge
合併程式碼回 master 分支後，Pull Request 保存了程式碼修改的歷史記錄。任何人都可再來查看，了解為何及如何作出決定。
可以透過將特定的關鍵字放入 pull 取請求訊息中，將問題與程式碼做關聯。當你的 pull 取請求被 merge，相關的問題也將被關閉。
GitLab Flow
Upsteam First
GitLab flow 的原則是”上游優先”（upsteam first），即只存在一個主分支master，它是所有分支的”上游”。只有上游分支採納的程式修改，才能應用到其他分支。
對於”持續發佈”的專案，它建議在master分支以外，再建立不同的環境分支。比如，”開發”的分支是 master，”預製作”的分支是 pre-production ，”產品”的分支是 production。
Master 是 pre-production 的”上游”，pre-production 又是 production 的”上游”。修改內容必須由”上游”向”下游”發展。比如，生產環境出現了bug，這時就要新建一個分支，先把它 merge 到 master ，確認沒有問題，再 cherry-pick 到 pre-production ，這一步也沒有問題，才進入 production ，藉此確保程式被充分測試過。
只有緊急情況，才允許跳過上游，直接合併到下游分支。
當對外發佈軟體的時候，才需要創建 release 分支。對外發佈版本的記錄是非常重要的，如果線上出現了一個問題，需要知道問題出現對應版本的代碼，才能準確定位問題。
發現問題，就從對應版本分支創建修復分支，完成之後，先合併到 master，才能再合併到 release 分支，遵循 “上游優先” 原則。
Releae
版本記錄是通過 master 上的 tag 來記錄。發現問題，創建 hotfix 分支，完成之後合併到 master 和 develop。
建議每一個穩定版本，都要從 master 分支拉出一個分支，比如 2–3-stable、2–4-stable 等等。
