在這篇文章中，我們將會討論最受Git用戶歡迎的幾種分支工作流程，您可以選擇最適合自己的方式。
Git Flow
Git工作流是最廣為人知的工作流。由Vincent Driessen 在2010年所發(fā)明，這種工作流建立在兩個具有永久生命周期的分支基礎(chǔ)之上：
master分支 - 對應(yīng)生產(chǎn)環(huán)境的線上代碼。所有開發(fā)代碼都會在某個時間點合并到master分支。
develop分支 - 對應(yīng)的是預(yù)生產(chǎn)的代碼。當功能分支開發(fā)完畢之后，會被合并到develop分支。
與之并行的，是在開發(fā)周期之內(nèi)，還會使用一些其他類型的分支以便支持開發(fā)流程：
feature-* ( * 表示通配符，下同) 分支 — 功能分支用來開發(fā)下次發(fā)布包含的新功能。這些分支應(yīng)當都是從develop分支派生出來，然后最終也應(yīng)該合并回develop分支。
hotfix-* 分支 — 當master分支中含有不應(yīng)出現(xiàn)的狀況時，則有必要派生出hotfix分支對master分支進行緊急修復(fù)。這些分支應(yīng)當派生自master 分支，并且最終應(yīng)當同時合并回master 和develop 分支。
release-* 分支 — release 分支用于準備一次新的生產(chǎn)環(huán)境版本更新。創(chuàng)建release-*分支用來修復(fù)一些在測試環(huán)境未發(fā)現(xiàn)的小BUG，以及更新此版本的原信息。其應(yīng)當派生自develop分支，并且最終同時合并回master 分支和 develop分支。
優(yōu)勢
在項目周期之內(nèi)，該工作流保證任何時刻兩個主要分支都是處于純凈狀態(tài)的
由于遵循系統(tǒng)化的模式，因此分支命名容易理解
大多數(shù)Git工具都支持該工作流的擴展工具
當項目中需要同時維護多個生產(chǎn)版本時，該工作流模式非常理想
缺陷
Git 的歷史記錄將變得異?；靵y，可讀性很差
master / develop 分支的割裂使CI/CD流程變得更加困難
當項目維護單一生產(chǎn)環(huán)境版本時，該工作流則不適用
GitHub Flow
GitHub 工作流是一個輕型的工作流，它是GitHub 在2011年創(chuàng)建，其工作流遵循以下6個原則：
任何時刻的master分支代碼都是可以用來部署的
任何新變更都需要從master派生出一個分支，并且為其起一個描述新變更內(nèi)容的名字：比如 new-oauth2-scopes
在本地提交該新分支變更，并且應(yīng)經(jīng)常性的向服務(wù)器端該同名分支推送變更
當你需要幫助、反饋，或認為新分支可以合并的時候，新建一個pull request
只有在其他人review通過之后，新分支才允許合并到
master分支一旦新分支被合并推送至
master分支，master分支應(yīng)當立即進行部署
優(yōu)勢
該工作流對于CI/CD流程友好
是Git工作流的一種簡版替換
當項目維護單一生產(chǎn)環(huán)境版本時，該工作流適用
缺陷
生產(chǎn)環(huán)境對應(yīng)的代碼極易處于不穩(wěn)定狀態(tài)
對于依賴發(fā)布計劃的項目無法充分支持
該工作流并不涉及關(guān)于部署，環(huán)境，發(fā)布和問題等方面的解決方案
當項目維護多生產(chǎn)環(huán)境版本時，該工作流不適用
GitLab Flow
GitLab工作流由GitLab創(chuàng)建于2014年。這種工作流將功能驅(qū)動的開發(fā)模式與問題跟蹤結(jié)合在一起。與GitHub工作流最大的不同，是GitLab工作流新創(chuàng)建了與環(huán)境相關(guān)的分支（比如，staging分支和production分支），適用于每次合并功能分支后不需馬上部署至生產(chǎn)環(huán)境的項目（如SaaS軟件，移動軟件項目等）。
GitLab工作流遵循以下11條原則：
使用功能分支進行開發(fā)，而不是直接在
master分支上提交代碼 （如果你的開發(fā)主分支是master的話，下同）測試每一次commit，而不僅僅是對
master分支進行測試在所有commits上運行自動化測試（如果你的測試腳本運行時間超過5分鐘，就讓他們并行）
在合并代碼之前進行code review，而不是在合并之后
以分支名或者tag為準進行自動化的部署
tag由人來設(shè)定，而不是CI
發(fā)布版本應(yīng)建立在tag上
已push的commits永遠不要進行rebase
所有人從
master派生新分支，最終合并回`master修復(fù)bug時應(yīng)該優(yōu)先修復(fù)
master分支的代碼，修復(fù)之后再cherry-pick到線上分支commit messages 要有意義
優(yōu)勢
相對于前兩種工作流，GitLab工作流定義了如何進行CI和CD流程的整合
提交歷史會非常清爽，歷史信息看上去會更具可讀性（參見：為何開發(fā)人員應(yīng)該使用squash and merge, 而不是僅僅merge）
當項目維護單一生產(chǎn)環(huán)境版本時，該工作流適用
缺陷
比GitHub工作流更加復(fù)雜
當項目維護多生產(chǎn)環(huán)境版本時，將會變得和Git Flow一樣復(fù)雜
One Flow
The One Flow is a proposed alternative in article GitFlow considered harmful by Adam Ruka, written in 2015. The main condition that needs to be satisfied in order to use OneFlow is that every new production release is based on the previous release. The most difference between One Flow and Git Flow that it not has develop branch.
One Flow 最初在GitFlow considered harmful by Adam Ruka, 2015這篇文章中提出，作為Git Flow的另一種選擇。使用One Flow需要滿足的最重要的條件，是生產(chǎn)版本的每一次更新都基于前一生產(chǎn)版本，與Git Flow最大的區(qū)別是沒有develop這一分支。
優(yōu)勢
提交歷史會非常清爽，歷史信息看上去會更具可讀性（參見：為何開發(fā)人員應(yīng)該使用squash and merge, 而不是僅僅merge）
靈活的團隊協(xié)作機制
當項目維護單一生產(chǎn)環(huán)境版本時，該工作流適用
缺陷
自動化CI/CD能力的項目慎用
功能分支不明確，不適用持續(xù)集成
當項目維護多生產(chǎn)環(huán)境版本時，該工作流不適用
參考
翻譯自：https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf
