一、Git常見工作流
Git三種常見的工作流：Git Flow、GitHub Flow 、GitLab Flow
二、Git Flow
Git Flow 是最早誕生也是最早被廣泛使用的工作流程。
在 Git Flow 中，有兩個長期存在且不會被刪除的分支：master 和 develop。
在這兩個分支中，master 主要用于對外發(fā)布穩(wěn)定的新版本，該分支時常保持著軟件可以正常運行的狀態(tài)，由于要維護這一狀態(tài)，所以不允許開發(fā)者直接對 master 分支的代碼進行修改和提交，其他分支的開發(fā)工作進展到可以發(fā)布的程度后，將會與 master 分支進行合并，并且這一合并只在發(fā)版時進行，發(fā)布時將會附加版本編號的 Git 標(biāo)簽。
develop 則用來存放我們最新開發(fā)的代碼，這個分支是我們開發(fā)過程中代碼中心分支，這個分支也不允許開發(fā)者直接進行修改和提交。程序員要以 develop 分支為起點新建 feature 分支，在 feature 分支中進行新功能的開發(fā)或者代碼的修正，也就是說 develop 分支維系著開發(fā)過程中的最新代碼，以便程序員創(chuàng)建 feature 分支進行自己的工作。
注意 develop 合并的時候，不要使用 fast-farward merge，建議加上 --no-ff 參數(shù)，這樣在 master 上就會有合并記錄，關(guān)于這兩個的區(qū)別，大家可以參數(shù)松哥之前的 Git 教程，這里不再贅述。
除了這兩個永久分支，還有三個臨時分支：feature branches、hotfixes 以及 release branches。我們分別來看。
2.1 feature branches
這個是特性分支，也叫功能分支，當(dāng)你需要開發(fā)一個新的功能的時候，可以新建一個 feature-xxx 的分支，在里邊開發(fā)新功能，這也是我們?nèi)粘９ぷ鞯拇蟊緺I，開發(fā)完成后，將之并入 develop 分支中，如下圖：
2.2 hotfixes branches
這個分支看名字就是用來修復(fù) BUG 的，當(dāng)我們的項目上線后，發(fā)現(xiàn)有 BUG 需要修復(fù)，那么就從 Master 上拉一個名為 fixbug-xxx 的分支，然后進行 BUG 修復(fù)，修復(fù)完成后，再將代碼合并到 Master 和 Develop 兩個分支中，然后刪除 hotfix 分支，如下圖：
2.3 release branches
這個是發(fā)版的時候拉的分支，當(dāng)我們所有的功能做完之后，準(zhǔn)備要將代碼合并到 master 的時候，從 develop 上拉一個 release-xxx 分支出來，這個分支一般處理發(fā)版前的一些提交以及客戶體驗之后小 BUG 的修復(fù)（BUG 修復(fù)后也可以將之合并進 develop），不要在這個里邊去開發(fā)功能，在預(yù)發(fā)布結(jié)束后，將該分支合并進 develop 以及 master，然后刪除 release，如下圖：
三、GitHub Flow
GitHub Flow 相比于 Git Flow 就要容易很多了，GitHub Flow 也是 GitHub 上使用的工作流程，如果你想?yún)⑴c GitHub 上的某一個開源項目，那么不妨看看 GitHub Flow。官方給的 GitHub Flow 流程如下：
- 第一步：根據(jù)需求，從master拉出新分支，不區(qū)分功能分支或補丁分支。
- 第二步：新分支開發(fā)完成后，或者需要討論的時候，就向master發(fā)起一個pull request（簡稱PR）。
- 第三步：Pull Request既是一個通知，讓別人注意到你的請求，又是一種對話機制，大家一起評審和討論你的代碼。對話過程中，你還可以不斷提交代碼。
- 第四步：你的Pull Request被接受，合并進master，重新部署后，原來你拉出來的那個分支就被刪除。（先部署再合并也可。）
GitHub 工作流雖然用著很簡單，但是他的問題也很明顯，就是沒有對常見的工作場景中的問題提出解決辦法。GitHub Flow這種方式，要保證高質(zhì)量，對于貢獻者的素質(zhì)要求很高，換句話說，如果代碼貢獻者素質(zhì)不那么高，質(zhì)量就無法得到保證。
四、GitLab Flow
Gitlab flow 是 Git flow 與 Github flow 的綜合。它吸取了兩者的優(yōu)點，既有適應(yīng)不同開發(fā)環(huán)境的彈性，又有單一主分支的簡單和便利。它是 Gitlab.com 推薦的做法。
Gitlab flow 的最大原則叫做”上游優(yōu)先”（upsteam first），即只存在一個主分支master，它是所有其他分支的”上游”。只有上游分支采納的代碼變化，才能應(yīng)用到其他分支。
對于”持續(xù)發(fā)布”的項目，它建議在master分支以外，再建立不同的環(huán)境分支。比如，”開發(fā)環(huán)境”的分支是master，”預(yù)發(fā)環(huán)境”的分支是pre-production，”生產(chǎn)環(huán)境”的分支是production。
只有緊急情況，才允許跳過上游，直接合并到下游分支。對于”版本發(fā)布”的項目，建議的做法是每一個穩(wěn)定版本，都要從master分支拉出一個分支，比如2-3-stable、2-4-stable等等。
GitLab flow 如何處理hotfix？ Git Flow之所以這么復(fù)雜，一大半原因就是把hotfix考慮得太周全了。hotfix的意思是，當(dāng)代碼部署到產(chǎn)品環(huán)境之后發(fā)現(xiàn)的問題，需要火速fix。GitLab Flow 可以基于后續(xù)分支，修改后上線。
4.1 采用GitLab Flow工作流程
新的迭代開始，所有開發(fā)人員從主干master拉個人分支開發(fā)特性, 分支命名規(guī)范 feature-name
開發(fā)完成后，在迭代結(jié)束前，合入master分支
master分支合并后，自動cicd到dev環(huán)境
開發(fā)自測通過后，從master拉取要發(fā)布的分支，
release-$version，將這個分支部署到測試環(huán)境進行測試測出的bug，通過從
release-$version拉出分支進行修復(fù)，修復(fù)完成后，再合入release-$version正式發(fā)布版本，如果上線后，又有bug，根據(jù)5的方式處理
等發(fā)布版本穩(wěn)定后，將
release-$version反合入主干
轉(zhuǎn)載自：Git 最佳實踐，什么才是最佳工作流？
