1.背景介紹

什么是Git工作流？

Git工作流你可以理解為工作中團(tuán)隊(duì)成員遵守的一種代碼管理方案，在Git中有以下幾種工作流方案作為方案指導(dǎo)。

1、集中式工作流

2、功能分支工作流

3、Gitflow工作流

4、Forking工作流

2.知識(shí)剖析

1、集中式工作流

這種工作方式跟svn類似，它只有一個(gè)master分支，開(kāi)發(fā)者會(huì)先把遠(yuǎn)程的倉(cāng)庫(kù)克隆到本地，之后的修 改和提交都在本地操作，直到在某個(gè)合適的時(shí)間點(diǎn)將本地的代碼合入到遠(yuǎn)程master。這種工作流比 較適合小團(tuán)隊(duì)，因?yàn)樾F(tuán)隊(duì)可能不會(huì)太多的協(xié)作和合流的動(dòng)作。

2、功能分支工作流

這種工作流關(guān)注功能開(kāi)發(fā)，不直接往master提交代碼保證它是穩(wěn)定并且干凈的，而是從master拉 取feature分支進(jìn)行功能開(kāi)發(fā)，團(tuán)隊(duì)成員根據(jù)分工拉取不同的功能分支來(lái)進(jìn)行不同的功能開(kāi)發(fā)，這樣 就可以完全隔離開(kāi)每個(gè)人的工作。當(dāng)功能開(kāi)發(fā)完成后，會(huì)向master分支發(fā)起Pull Request，只有審 核通過(guò)的代碼才真正允許合入master，這樣就加強(qiáng)了團(tuán)隊(duì)成員之間的代碼交流。

3、Gitflow工作流

它會(huì)相對(duì)復(fù)雜一點(diǎn)，但它非常適合用來(lái)管理大型項(xiàng)目的發(fā)布和維護(hù)，后面也會(huì)詳細(xì)講下這一塊。 貫穿整個(gè)開(kāi)發(fā)周期，master和develop分支是一直存在的，master分支可以被視為穩(wěn)定的分支， 而develop分支是相對(duì)穩(wěn)定的分支，特性開(kāi)發(fā)會(huì)在feature分支上進(jìn)行，發(fā)布會(huì)在release分支上 進(jìn)行，而bug修復(fù)則會(huì)在hotfix分支上進(jìn)行。

4、Forking工作流

Forking工作流對(duì)于開(kāi)源項(xiàng)目貢獻(xiàn)者一定不陌生了，它有一個(gè)公開(kāi)的中央倉(cāng)庫(kù)，其他貢獻(xiàn) 者可以Fork（克?。┻@個(gè)倉(cāng)庫(kù)作為你自己的私有倉(cāng)庫(kù)，開(kāi)源項(xiàng)目維護(hù)者可以直接往中央倉(cāng)庫(kù) push代碼，而代碼貢獻(xiàn)者只能將代碼push到自己的私有倉(cāng)庫(kù)，只有項(xiàng)目維護(hù)者接受代碼貢獻(xiàn) 者往中央倉(cāng)庫(kù)發(fā)起的pull request才會(huì)真正合入。

3.常見(jiàn)問(wèn)題

Gitflow工作流的工作方式?

4.解決方案

Gitflow工作流是經(jīng)典模型，處于核心位置，體現(xiàn)了工作流的經(jīng)驗(yàn)和精髓。

Gitflow工作流通過(guò)為功能開(kāi)發(fā)、發(fā)布準(zhǔn)備和維護(hù)分配獨(dú)立的分支，讓發(fā)布迭代過(guò)程更流暢。嚴(yán)格的分支模型也為大型項(xiàng)目提供了一些非常必要的結(jié)構(gòu)。

1、歷史分支

相對(duì)使用僅有的一個(gè)master分支，Gitflow工作流使用2個(gè)分支來(lái)記錄項(xiàng)目的歷史。 master分支存儲(chǔ)了正式發(fā)布的歷史，而develop分支作為功能的集成分支。 這樣也方便master分支上的所有提交分配一個(gè)版本號(hào)。

2、功能分支

每個(gè)新功能位于一個(gè)自己的分支，這樣可以push到中央倉(cāng)庫(kù)以備份和協(xié)作。 但功能分支不是從master分支上拉出新分支，而是使用develop分支作為父分支。 當(dāng)新功能完成時(shí)，合并回develop分支。 新功能提交應(yīng)該從不直接與master分支交互。 從各種含義和目的上來(lái)看，功能分支加上develop分支就是功能分支工作流的用法。但Gitflow工作流沒(méi)有在這里止步。

3、發(fā)布分支

一旦develop分支上有了做一次發(fā)布（或者說(shuō)快到了既定的發(fā)布日）的足夠功能，就從develop分支上checkout一個(gè)發(fā)布分支。 新建的分支用于開(kāi)始發(fā)布循環(huán)，所以從這個(gè)時(shí)間點(diǎn)開(kāi)始之后新的功能不能再加到這個(gè)分支上—— 這個(gè)分支只應(yīng)該做Bug修復(fù)、文檔生成和其它面向發(fā)布任務(wù)。 一旦對(duì)外發(fā)布的工作都完成了， 發(fā)布分支合并到master分支并分配一個(gè)版本號(hào)打好Tag。 另外，這些從新建發(fā)布分支以來(lái)的做的修改要合并回develop分支。

使用一個(gè)用于發(fā)布準(zhǔn)備的專門分支，使得一個(gè)團(tuán)隊(duì)可以在完善當(dāng)前的發(fā)布版本的同時(shí)，另一個(gè)團(tuán)隊(duì)可以繼續(xù)開(kāi)發(fā)下個(gè)版本的功能。 這也打造定義良好的開(kāi)發(fā)階段。

4、維護(hù)分支

維護(hù)分支或說(shuō)是熱修復(fù)（hotfix）分支用于生成快速給產(chǎn)品發(fā)布版本（production releases）打補(bǔ)丁， 這是唯一可以直接從master分支fork出來(lái)的分支。 修復(fù)完成，修改應(yīng)該馬上合并回master分支和dev elop分支（當(dāng)前的發(fā)布分支），master分支應(yīng)該用新的版本號(hào)打好Tag。

為Bug修復(fù)使用專門分支，讓團(tuán)隊(duì)可以處理掉問(wèn)題而不用打斷其它工作或是等待下一個(gè)發(fā)布循環(huán)。 你可以把維護(hù)分支想成是一個(gè)直接在master分支上處理的臨時(shí)發(fā)布。

5.編碼實(shí)戰(zhàn)

由于本次均為理論性內(nèi)容，所以以示例為主

下面的示例演示本工作流如何用于管理單個(gè)發(fā)布循環(huán)。假設(shè)你已經(jīng)創(chuàng)建了一個(gè)中央倉(cāng)庫(kù)。

1、創(chuàng)建開(kāi)發(fā)分支：

第一步為master分支配套一個(gè)develop分支。簡(jiǎn)單來(lái)做可以本地創(chuàng)建一個(gè)空的develop分支，push到服務(wù)器上。 以后這個(gè)分支將會(huì)包含了項(xiàng)目的全部歷史，而master分支將只包含了部分歷史。 其它開(kāi)發(fā)者這時(shí)應(yīng)該克隆中央倉(cāng)庫(kù)，建好develop分支的跟蹤分支： 現(xiàn)在每個(gè)開(kāi)發(fā)都有了這些歷史分支的本地拷貝。

2、小紅和小明開(kāi)始開(kāi)發(fā)新功能：

這個(gè)示例中，小紅和小明開(kāi)始各自的功能開(kāi)發(fā)。他們需要為各自的功能創(chuàng)建相應(yīng)的分支。新分支不是基于master分支，而是應(yīng)該基于develop分支，他們用老套路添加提交到各自功能分支上：編輯、暫存、提交。

3、小紅完成功能開(kāi)發(fā)

添加了提交后，小紅覺(jué)得她的功能OK了。如果團(tuán)隊(duì)使用Pull Requests，這時(shí)候可以發(fā)起一個(gè)用于合并到develop分支。 否則她可以直接合并到她本地的develop分支后push到中央倉(cāng)。 在合并功能前確保develop分支是最新的。注意，功能決不應(yīng)該直接合并到master分支。沖突解決方法和集中式工作流一樣。

4、小紅開(kāi)始準(zhǔn)備發(fā)布

這個(gè)時(shí)候小明正在實(shí)現(xiàn)他的功能，小紅開(kāi)始準(zhǔn)備她的第一個(gè)項(xiàng)目正式發(fā)布。 像功能開(kāi)發(fā)一樣，她用一個(gè)新的分支來(lái)做發(fā)布準(zhǔn)備。這一步也確定了發(fā)布的版本號(hào)。

這個(gè)分支是清理發(fā)布、執(zhí)行所有測(cè)試、更新文檔和其它為下個(gè)發(fā)布做準(zhǔn)備操作的地方，像是一個(gè)專門用于改善發(fā)布的功能分支。 只要小紅創(chuàng)建這個(gè)分支并push到中央倉(cāng)庫(kù)，這個(gè)發(fā)布就是功能凍結(jié)的。任何不在develop分支中的新功能都推到下個(gè)發(fā)布循環(huán)中。

5、小紅完成發(fā)布

一旦準(zhǔn)備好了對(duì)外發(fā)布，小紅合并修改到master分支和develop分支上，刪除發(fā)布分支。

合并回develop分支很重要，因?yàn)樵诎l(fā)布分支中已經(jīng)提交的更新需要在后面的新功能中也要是可用的。

發(fā)布分支是作為功能開(kāi)發(fā)（develop分支）和對(duì)外發(fā)布（master分支）間的緩沖。 只要有合并到master分支，就應(yīng)該打好Tag以方便跟蹤。

Git有提供各種勾子（hook），即倉(cāng)庫(kù)有事件發(fā)生時(shí)觸發(fā)執(zhí)行的腳本。 可以配置一個(gè)勾子，在你push中央倉(cāng)庫(kù)的master分支時(shí)，自動(dòng)構(gòu)建好對(duì)外發(fā)布。

6、最終用戶發(fā)現(xiàn)Bug

對(duì)外發(fā)布后，小紅回去和小明一起做下個(gè)發(fā)布的新功能開(kāi)發(fā)，直到有最終用戶開(kāi)了一個(gè)Ticket抱怨當(dāng)前版本的一個(gè)Bug。 為了處理Bug，小紅（或小明）從master分支上拉出了一個(gè)維護(hù)分支，提交修改以解決問(wèn)題，然后直接合并回master分支。 就像發(fā)布分支，維護(hù)分支中新加這些重要修改需要包含到develop分支中，所以小紅要執(zhí)行一個(gè)合并操作。 然后就可以安全地刪除這個(gè)分支了。

6. 擴(kuò)展思考

SourceTree里GitFlow的使用

1、初始化

SourceTree會(huì)自動(dòng)化進(jìn)行一些操作，最明顯的變化是項(xiàng)目代碼庫(kù)里自動(dòng)增加了一個(gè)develop的分支。

將新創(chuàng)建的develop分支推送到遠(yuǎn)端倉(cāng)庫(kù)。

從此，代碼庫(kù)里就存在了兩個(gè)永久性的分支：master和develop，未來(lái)所有的開(kāi)發(fā)工作都圍繞這兩個(gè)分支進(jìn)行派生跟合并。

2、之前提到，項(xiàng)目里有兩個(gè)永久的分支：master和develop。這兩個(gè)分支也被稱為“歷史性”分支，在其后的開(kāi)發(fā)工作中， Gitflow模型支持在feature、release、hotfix分支上折騰，這樣也有效避免了不同類型的開(kāi)發(fā)工作在代碼層級(jí)的耦合和干擾。

這三個(gè)分支的用途、派生來(lái)源分支和合并目標(biāo)分支如下：

feature，功能開(kāi)發(fā)分支，用于承接具體功能需求的開(kāi)發(fā)

派生于develop

合并于develop

hotfix，bug修復(fù)分支，用于解決線上運(yùn)行環(huán)境發(fā)現(xiàn)的bug

派生于master

合并于master、develop

release，版本發(fā)布分支，用于完成發(fā)布準(zhǔn)備的

派生于develop

合并于master、develop

跟“歷史性”分支相反，這三類分支都是短期分支，針對(duì)他們的工作內(nèi)容完成后，一般都要進(jìn)行刪除。工作內(nèi)容完成的標(biāo)識(shí)有兩個(gè)：開(kāi)發(fā)完成、合并完成，缺一不可。

3、我們使用sourcetree來(lái)實(shí)際演示一下（詳細(xì)步驟請(qǐng)看視頻）

4、三類臨時(shí)性分支中，hotfix和release的結(jié)果都要合并到master和develop中，為什么？因?yàn)樗鼈兊男薷慕Y(jié)果持續(xù)影響這后續(xù)的開(kāi)發(fā)和維護(hù)，必須合并以保證代碼的一致性。

如果你沒(méi)有認(rèn)識(shí)到這個(gè)特性很有用，那是因?yàn)槟愕拈_(kāi)發(fā)工作還沒(méi)有復(fù)雜到一個(gè)程度，一個(gè)必須要規(guī)避代碼干擾、保證并行推進(jìn)的程度。

對(duì)于小型項(xiàng)目和團(tuán)隊(duì)來(lái)說(shuō)，基于GIT的中心式協(xié)作模型和特性分支模型就足夠了；GitFlow模型適合中型、大型項(xiàng)目和團(tuán)隊(duì)。

7.參考文獻(xiàn)

Git工作流指南： https://github.com/xirong/my-git/blob/master/git-workflow-tutorial.md#231-工作方式

Git 工作流的一些經(jīng)驗(yàn)分享：http://blog.csdn.net/wwj_748/article/details/55226044

SourceTree里GitFlow的使用：http://www.cnblogs.com/niwanglong385/articles/5645835.html

8.更多討論

一定要按照上述幾種工作流來(lái)進(jìn)行開(kāi)發(fā)嗎？

git工作流是作為方案指導(dǎo)而不是條例規(guī)定。在展示了各種工作流可能的用法后，你可以從不同的工作流中挑選或揉合出一個(gè)滿足你自己需求的工作流。

只有選用最合適自己團(tuán)隊(duì)的工作流才能有效的提高開(kāi)發(fā)效率，上面提到的一些工作流模式都有各自 的適用場(chǎng)景，如何選用適合自己團(tuán)隊(duì)的工作流得結(jié)合團(tuán)隊(duì)成員的實(shí)際情況，看團(tuán)隊(duì)成員對(duì)于工作流的理解程度，還有對(duì)于工作流的執(zhí)行程度。

編碼實(shí)戰(zhàn)演示的工作流只是可能用法的例子，而不是在實(shí)際工作中使用Git不可違逆的條例。 所以不要畏懼按自己需要對(duì)工作流的用法做取舍。不變的目標(biāo)就是讓Git為你所用。

問(wèn)題：

1、hook是什么？

答：Git有提供各種勾子（hook），即倉(cāng)庫(kù)有事件發(fā)生時(shí)觸發(fā)執(zhí)行的腳本。 比如可以配置一個(gè)勾子，在你push中央倉(cāng)庫(kù)的master分支時(shí)，自動(dòng)構(gòu)建好對(duì)外發(fā)布。

2、SourceTree的GitFlow工作流的合并與分支是自動(dòng)設(shè)定的嗎？

答：合適，在SourceTree中，使用GitFlow工作流會(huì)自動(dòng)給功能分支、發(fā)布分支、修復(fù)分支設(shè)定從哪個(gè)分支拉取以及合并到哪些分支。

3、如何解決沖突？

答：解決沖突需要自己手動(dòng)解決，選擇merge還是選擇哪個(gè)版本，merge可以選擇外部工具，也可以用SourceTree來(lái)解決。

_騰訊視頻

PPT地址：https://ptteng.github.io/PPT/PPT/css-02-What%20is%20Gitflow%20Workflow.html#/

視頻地址：https://v.qq.com/x/page/w0535vqz6tq.html

今天的分享就到這里啦，歡迎大家點(diǎn)贊、轉(zhuǎn)發(fā)、留言、拍磚~

下期預(yù)告：瀏覽器如何渲染頁(yè)面?不見(jiàn)不散~

------------------------------------------------------------------------------------------------------------------------

技能樹(shù).IT修真院

“我們相信人人都可以成為一個(gè)工程師，現(xiàn)在開(kāi)始，找個(gè)師兄，帶你入門，掌控自己學(xué)習(xí)的節(jié)奏，學(xué)習(xí)的路上不再迷?！?。

這里是技能樹(shù).IT修真院，成千上萬(wàn)的師兄在這里找到了自己的學(xué)習(xí)路線，學(xué)習(xí)透明化，成長(zhǎng)可見(jiàn)化，師兄1對(duì)1免費(fèi)指導(dǎo)?？靵?lái)與我一起學(xué)習(xí)吧~

我的邀請(qǐng)碼：96194340，或者你可以直接點(diǎn)擊此鏈接：http://www.jnshu.com/login/1/96194340