開篇
Git 三大特色玖翅，分支站削，暫存區(qū)，工作流，今天終于要寫到 WorkFlow 了丢胚，我彷佛已經(jīng)看到勝利的曙光，走起堡纬。
何謂工作流
WorkFlow 的字面意思撰糠，工作流，即工作流程故慈。在分支篇里板熊，有說過這樣的話：因?yàn)橛蟹种У拇嬖冢艠?gòu)成了多工作流的特色察绷。事實(shí)的確如此干签，因?yàn)轫?xiàng)目開發(fā)中，多人協(xié)作拆撼，分支很多容劳，雖然各自在分支上互不干擾，但是我們總歸需要把分支合并到一起情萤，而且真實(shí)項(xiàng)目中涉及到很多問題鸭蛙，例如版本迭代，版本發(fā)布筋岛，bug 修復(fù)等娶视，為了更好的管理代碼，需要制定一個(gè)工作流程睁宰，這就是我們說的工作流肪获，也有人叫它分支管理策略。
工作流不涉及任何命令柒傻，因?yàn)樗褪且粋€(gè)規(guī)則孝赫，完全由開發(fā)者自定義，并且自遵守红符，正所謂無規(guī)矩不成方圓青柄，就是這個(gè)道理伐债。
工作流最受歡迎榜
目前使用度最高的工作流前三名（排名不分先后哈）分別是以下三種：
其中 Git Flow 出現(xiàn)的最早，GitHub Flow 在 Git Flow 的基礎(chǔ)上致开，做了一些優(yōu)化峰锁，適用于持續(xù)版本的發(fā)布，而 GitLab Flow 出現(xiàn)的時(shí)間比較晚双戳，所以綜合前面兩種工作流的優(yōu)點(diǎn)虹蒋，制定而成的一個(gè)工作流。
Git Flow
這個(gè)工作流飒货，是 Vincent Driessen 2010 年發(fā)布出來的他自己的分支管理模型魄衅，到現(xiàn)在為止，使用度非常高塘辅，我自己管理項(xiàng)目用的就是這個(gè)晃虫，也可以說是比較熟悉的啦。
Git Flow 的分支結(jié)構(gòu)很特別扣墩，按功能來說傲茄，可以分支為5種分支，從5 種分支的生命時(shí)間上沮榜，又可以分別歸類為長期分支和暫時(shí)分支，或者更貼切描述為喻粹，主要分支和協(xié)助分支蟆融。
主要分支：
在采用 Git Flow 工作流的項(xiàng)目中，代碼的中央倉庫會(huì)一直存在以下兩個(gè)長期分支：
- master
- develop
其中 origin/master 分支上的最新代碼永遠(yuǎn)是版本發(fā)布狀態(tài)守呜。origin／develop 分支則是最新的開發(fā)進(jìn)度型酥。
當(dāng) develop 上的代碼達(dá)到一個(gè)穩(wěn)定的狀態(tài)，可以發(fā)布版本的時(shí)候查乒，develop上這些修改會(huì)以某種特別方式被合并到 master 分支上弥喉，然后標(biāo)記上對應(yīng)的版本標(biāo)簽。
協(xié)助分支：
除了主要分支玛迄，Git Flow 的開發(fā)模式還需要一系列的協(xié)助分支由境，來幫助更好的功能的并行開發(fā)，簡化功能開發(fā)和問題修復(fù)蓖议。是的虏杰，就是下面的三類分支。這類分支是暫時(shí)分支非常無私奉獻(xiàn)勒虾，在需要它們的時(shí)候纺阔，迫切地創(chuàng)建，用完它們的時(shí)候修然，又揮揮衣袖地徹底消失笛钝。
協(xié)助分支分為以下幾類：
- Feature Branch
- Release Branch
- Hotfix Branch
Feature 分支用來做分模塊功能開發(fā)质况，命名看開發(fā)者喜好，不要和其他類型的分支命名弄混淆就好玻靡，舉個(gè)壞例子结榄，命名為 master 就是一個(gè)非常不妥當(dāng)?shù)呐e動(dòng)。模塊完成之后啃奴，會(huì)合并到 develop 分支潭陪，然后刪除自己。
Release 分支用來做版本發(fā)布的預(yù)發(fā)布分支最蕾，建議命名為 release-xxx依溯。例如在軟件 1.0.0 版本的功能全部開發(fā)完成，提交測試之后瘟则，從 develop 檢出release-1.0.0 ,測試中出現(xiàn)的小問題黎炉，在 release 分支進(jìn)行修改提交，測試完畢準(zhǔn)備發(fā)布的時(shí)候醋拧，代碼會(huì)合并到 master 和 develop慷嗜，master 分支合并后會(huì)打上對應(yīng)版本標(biāo)簽 v1.0.0, 合并后刪除自己，這樣做的好處是丹壕，在測試的時(shí)候庆械，不影響下一個(gè)版本功能并行開發(fā)。
Hotfix 分支是用來做線上的緊急 bug 修復(fù)的分支,建議命名為 hotfix-xxx菌赖。當(dāng)線上某個(gè)版本出現(xiàn)了問題缭乘，將檢出對應(yīng)版本的代碼，創(chuàng)建 Hotfix 分支琉用，問題修復(fù)后堕绩，合并回 master 和 develop ，然后刪除自己邑时。這里注意奴紧，合并到 master 的時(shí)候，也要打上修復(fù)后的版本標(biāo)簽晶丘。
Merge 加上 no-ff 參數(shù)
需要說明的是黍氮，Git Flow 的作者 Vincent Driessen 非常建議，合并分支的時(shí)候浅浮，加上 no-ff 參數(shù)滤钱，這個(gè)參數(shù)的意思是不要選擇 Fast-Forward 合并方式，而是策略合并脑题，策略合并會(huì)讓我們多一個(gè)合并提交件缸。這樣做的好處是保證一個(gè)非常清晰的提交歷史，可以看到被合并分支的存在叔遂。
下面是對比圖他炊，左側(cè)是加上參數(shù)的争剿，后者是普通的提交：
Git Flow 示意圖
下面這張圖，我在剛學(xué)習(xí) Git 的時(shí)候痊末，看到很多次這個(gè)圖蚕苇，然并卵，一直都沒看懂過凿叠，也不知道這張圖來自 Git Flow 涩笤，只能說，我當(dāng)初學(xué) Git 的方式的確不怎么認(rèn)真和系統(tǒng) 盒件。好在蹬碧，我現(xiàn)在已經(jīng)能看明白了這個(gè)圖，并且還寫了個(gè)博客炒刁，不得不感嘆恩沽，時(shí)光真是好神奇，讓人都遇到不一樣的自己翔始。
圖中畫了 Git Flow 的五種分支罗心，master，develop城瞎，feature branchs ,release branchs , hoxfixes渤闷，其中 master 和 develop 字體被加粗代表主要分支。master 分支每合并一個(gè)分支脖镀，無論是 hotfix 還是 release ,都會(huì)打一個(gè)版本標(biāo)簽肤晓。通過箭頭可以清楚的看到分支的開始和結(jié)束走向，例如 feature 分支從 develop 開始认然，最終合并回 develop ，hoxfixes 從 master 檢出創(chuàng)建漫萄，最后合并回 develop 和 master卷员，master 也打上了標(biāo)簽。
看懂之后腾务，覺著這個(gè)圖畫的還挺好看的毕骡，嗯，配色也不錯(cuò)岩瘦。
GitHub Flow
GitHub Flow 是大型程序員交友社區(qū) GitHub 制定并使用的工作流模型未巫，由 scott chacon 在 2011 年 8月 31 號正式發(fā)布。
文章中說启昧，因?yàn)?Git Flow 對于大部分開發(fā)人員和團(tuán)隊(duì)來說叙凡，稍微有些復(fù)雜，而且沒有 GUI 圖形頁面密末，只能命令行操作握爷，所以為了更好的解決這些問題跛璧，GitHub Flow 應(yīng)運(yùn)而生了。
GitHub Flow 示意圖
對比上面那張 Git flow 分支模型圖新啼，真的可以稱得上簡單明了啦追城，因?yàn)?GitHub Flow 推薦做法是只有一個(gè)主分支 master，團(tuán)隊(duì)成員們的分支代碼通過 pull Request 來合并到 master 上燥撞。
GitHub Flow 模型簡單說明
- 只有一個(gè)長期分支 master ,而且 master 分支上的代碼座柱，永遠(yuǎn)是可發(fā)布狀態(tài),一般 master 會(huì)設(shè)置
protected分支保護(hù)，只有有權(quán)限的人才能推送代碼到 master 分支物舒。 - 如果有新功能開發(fā)色洞，可以從 master 分支上檢出新分支。
- 在本地分支提交代碼茶鉴，并且保證按時(shí)向遠(yuǎn)程倉庫推送锋玲。
- 當(dāng)你需要反饋或者幫助，或者你想合并分支時(shí)涵叮，可以發(fā)起一個(gè) pull request惭蹂。
- 當(dāng) review 或者討論通過后，代碼會(huì)合并到目標(biāo)分支割粮。
- 一旦合并到 master 分支盾碗，應(yīng)該立即發(fā)布。
特色之 Pull Request
在我看來舀瓢，GitHub Flow 最大的特色就是 Pull Request 的提出廷雅，這是一個(gè)偉大的發(fā)明，它的用處并不僅僅是合并分支京髓，還有以下功能：
-
可以很好控制分支合并權(quán)限航缀。
分支不是你想合并就合并，需要對方同意吶
-
問題討論 或者 尋求其他小伙伴們的幫助堰怨。
和拉個(gè)討論組差不多芥玉，可以選擇相關(guān)的人參與，而且參與的人還可以向你的分支提交代碼备图，可以說灿巧，是非常適合代碼交流了。
-
代碼 Review 揽涮。
如果代碼寫的很爛抠藕，有了 pull request 提供的評論功能支持，準(zhǔn)備好接受來自 review 的實(shí)時(shí)吐槽吧蒋困。當(dāng)然你如果寫的很棒盾似，肯定也能被雙擊666的。
特色之 issue tracking 問題追蹤
日常開發(fā)中雪标，會(huì)用到很多第三方庫颜说，然后使用過程中购岗，出現(xiàn)了問題，是不是第一個(gè)反應(yīng)是去這個(gè)第三方庫的 GitHub 倉庫去搜索一下 issue 门粪，看沒有人遇到過喊积，項(xiàng)目維護(hù)者修復(fù)了沒有，一般未解決的 issue 是 open 狀態(tài)玄妈，已解決的會(huì)被標(biāo)記為 closed乾吻。這就是 issue tracking。
如果你是一個(gè)項(xiàng)目維護(hù)者拟蜻，除了標(biāo)記 issue 的開啟和關(guān)閉绎签，還可以給它標(biāo)記上不同的標(biāo)簽，來優(yōu)化項(xiàng)目酝锅。當(dāng)提交的時(shí)候诡必，如果提交信息中有 fix #1 等字段，可以自動(dòng)關(guān)閉對應(yīng)編號的 issue搔扁。
issue tracking 真的是非常適合開源項(xiàng)目爸舒。
如果你想體驗(yàn) GitHub Flow
GitHub 社區(qū)使用的就是這個(gè)工作流模型，而且?guī)椭臋n非常詳細(xì)稿蹲，可以建個(gè)項(xiàng)目扭勉，多耍耍。
GitLab Flow
這個(gè)工作流十分地年輕苛聘，是 GitLab 的 CEO Sytse Sijbrandij 在 2014 年 9月 29 正式發(fā)布出來的涂炎。因?yàn)槌霈F(xiàn)的比前面兩種工作流稍微晚一些，所以它有個(gè)非常大的優(yōu)勢设哗，集百家之長唱捣，補(bǔ)百家之短。
GitLab 既支持 Git Flow 的分支策略网梢，也有 GitHub Flow 的 Pull Request（ Merge Request ） 和 issue tracking震缭。
Git Flow & GitHub Flow 的瑕疵
當(dāng) Git Flow 出現(xiàn)后，它解決了之前項(xiàng)目管理的很讓人頭疼的分支管理澎粟，但是實(shí)際使用過程中，也暴露了很多問題：
- 默認(rèn)工作分支是 develop欢瞪，但是大部分版本管理工具默認(rèn)分支都是 master活烙，開始的時(shí)候總是需要切換很麻煩。
- Hotfix 和 Release 分支在需要版本快速迭代的項(xiàng)目中遣鼓，幾乎用不到啸盏，因?yàn)閯傞_發(fā)完就直接合并到 master 發(fā)版，出現(xiàn)問題 develop 就直接修復(fù)發(fā)布下個(gè)版本了骑祟。
- Hotfix 和 Release 分支回懦，一個(gè)從 master 創(chuàng)建气笙，一個(gè)從 develop 創(chuàng)建，使用完畢怯晕，需要合并回 develop 和 master潜圃。而且在實(shí)際項(xiàng)目管理中，很多開發(fā)者會(huì)忘記合并回 develop 或者 master舟茶。
GitHub Flow 的出現(xiàn)谭期，非常大程度上簡化了 Git Flow ，因?yàn)橹挥幸粋€(gè)長期分支 master吧凉，并且提供 GUI 操作工具隧出，一定程度上避免了上述的幾個(gè)問題，然而在一些實(shí)際問題面前阀捅，僅僅使用 master 分支顯然有點(diǎn)力不從心胀瞪，例如：
- 版本的延遲發(fā)布（例如 iOS 應(yīng)用審核到通過中間，可能也要在 master 上推送代碼）
- 不同環(huán)境的部署 （例如：測試環(huán)境饲鄙，預(yù)發(fā)環(huán)境凄诞，正式環(huán)境）
- 不同版本發(fā)布與修復(fù) （是的，只有一個(gè) master 分支真的不夠用）
GitLab Flow 解決方案
為了解決上面那些毛茸茸的小問題傍妒，GitLab Flow 給出了以下的解決方法幔摸。
版本的延遲發(fā)布--Prodution Branch
master 分支不夠，于是添加了一個(gè) prodution 分支颤练，專門用來發(fā)布版本既忆。
不同環(huán)境的部署--Environment Branches & Upstream First
每個(gè)環(huán)境，都對應(yīng)一個(gè)分支嗦玖，例如下圖中的 pre-production 和 prodution 分支都對應(yīng)不同的環(huán)境患雇，我覺得這個(gè)工作流模型比較適用服務(wù)端，測試環(huán)境宇挫，預(yù)發(fā)環(huán)境苛吱，正式環(huán)境，一個(gè)環(huán)境建一個(gè)分支器瘪。
這里要注意翠储，代碼合并的順序，要按環(huán)境依次推送橡疼，確保代碼被充分測試過,才會(huì)從上游分支合并到下游分支援所。除非是很緊急的情況，才允許跳過上游分支欣除，直接合并到下游分支住拭。這個(gè)被定義為一個(gè)規(guī)則，名字叫 “upstream first”，翻譯過來是 “上游優(yōu)先”滔岳。
版本發(fā)布分支--Release Branches & Upstream First
只有當(dāng)對外發(fā)布軟件的時(shí)候杠娱，才需要?jiǎng)?chuàng)建 release 分支。作為一個(gè)移動(dòng)端開發(fā)來說谱煤，對外發(fā)布版本的記錄是非常重要的摊求，如果線上出現(xiàn)了一個(gè)問題，需要拿到問題出現(xiàn)對應(yīng)版本的代碼趴俘，才能準(zhǔn)確定位問題睹簇。
在 Git Flow ,版本記錄是通過 master 上的 tag 來記錄。發(fā)現(xiàn)問題寥闪，創(chuàng)建 hotfix 分支太惠，完成之后合并到 master 和 develop。
在 GitLab Flow 疲憋，建議的做法是每一個(gè)穩(wěn)定版本凿渊，都要從master分支拉出一個(gè)分支，比如2-3-stable缚柳、2-4-stable等等埃脏。發(fā)現(xiàn)問題，就從對應(yīng)版本分支創(chuàng)建修復(fù)分支秋忙，完成之后彩掐，先合并到 master，才能再合并到 release 分支灰追，遵循 “上游優(yōu)先” 原則堵幽。
最后
這個(gè)博客，真的寫好久弹澎，因?yàn)槲抑皩ぷ髁鞯倪@個(gè)概念朴下，也只限于 Git Flow ，寫博客的過程中苦蒿，自己也學(xué)習(xí)到很多殴胧，我目前的工作項(xiàng)目中，使用的是 GitLab + Git Flow 這種混搭 Style佩迟，側(cè)面證明了 Git 的使用真的很靈活自由团滥。但是我很喜歡 GitHub 的 Pull Request 和 GitLab 的 Merge Request，以后會(huì)多嘗試报强。
GitHub Flow 和 GitLab Flow 的介紹很多都是來源于各自的英文介紹文檔灸姊，不對之處，還請?jiān)u論指證躺涝，下篇博客見厨钻。See you~
參考鏈接：
