1.背景介紹

什么是Git工作流？

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

1、集中式工作流

2、功能分支工作流

3、Gitflow工作流

4、Forking工作流

2.知識剖析

1、集中式工作流

這種工作方式跟svn類似，它只有一個master分支，開發(fā)者會先把遠程的倉庫克隆到本地，之后的修 改和提交都在本地操作，直到在某個合適的時間點將本地的代碼合入到遠程master。這種工作流比 較適合小團隊，因為小團隊可能不會太多的協(xié)作和合流的動作。

2、功能分支工作流

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

3、Gitflow工作流

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

4、Forking工作流

Forking工作流對于開源項目貢獻者一定不陌生了，它有一個公開的中央倉庫，其他貢獻 者可以Fork（克隆）這個倉庫作為你自己的私有倉庫，開源項目維護者可以直接往中央倉庫 push代碼，而代碼貢獻者只能將代碼push到自己的私有倉庫，只有項目維護者接受代碼貢獻 者往中央倉庫發(fā)起的pull request才會真正合入。

3.常見問題

Gitflow工作流的工作方式?

4.解決方案

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

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

1、歷史分支

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

2、功能分支

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

3、發(fā)布分支

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

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

4、維護分支

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

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

5.編碼實戰(zhàn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. 擴展思考

SourceTree里GitFlow的使用

1、初始化

SourceTree會自動化進行一些操作，最明顯的變化是項目代碼庫里自動增加了一個develop的分支。

將新創(chuàng)建的develop分支推送到遠端倉庫。

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

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

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

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

派生于develop

合并于develop

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

派生于master

合并于master、develop

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

派生于develop

合并于master、develop

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

3、我們使用sourcetree來實際演示一下（詳細步驟請看視頻）

4、三類臨時性分支中，hotfix和release的結(jié)果都要合并到master和develop中，為什么？因為它們的修改結(jié)果持續(xù)影響這后續(xù)的開發(fā)和維護，必須合并以保證代碼的一致性。

如果你沒有認識到這個特性很有用，那是因為你的開發(fā)工作還沒有復(fù)雜到一個程度，一個必須要規(guī)避代碼干擾、保證并行推進的程度。

對于小型項目和團隊來說，基于GIT的中心式協(xié)作模型和特性分支模型就足夠了；GitFlow模型適合中型、大型項目和團隊。

7.參考文獻

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

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

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

8.更多討論

一定要按照上述幾種工作流來進行開發(fā)嗎？

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

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

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

問題：

1、hook是什么？

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

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

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

3、如何解決沖突？

答：解決沖突需要自己手動解決，選擇merge還是選擇哪個版本，merge可以選擇外部工具，也可以用SourceTree來解決。

_騰訊視頻

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

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

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

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

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

技能樹.IT修真院

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

這里是技能樹.IT修真院，成千上萬的師兄在這里找到了自己的學(xué)習(xí)路線，學(xué)習(xí)透明化，成長可見化，師兄1對1免費指導(dǎo)。快來與我一起學(xué)習(xí)吧~

我的邀請碼：96194340，或者你可以直接點擊此鏈接：http://www.jnshu.com/login/1/96194340