摘要：同時(shí)，每一次更新，最好添加對(duì)應(yīng)的版本號(hào)標(biāo)簽。在這個(gè)分支上的代碼允許做小的缺陷修正準(zhǔn)備發(fā)布版本所需的各項(xiàng)說(shuō)明信息版本號(hào)發(fā)布時(shí)間編譯時(shí)間等等。版本號(hào)的命名可以依據(jù)項(xiàng)目定義的版本號(hào)命名規(guī)則進(jìn)行。

我說(shuō)的以下流程，sourceTree等工具已經(jīng)完美的支持了，鼠標(biāo)點(diǎn)兩下就完成了。簡(jiǎn)直是完美。

Feature Branch Workflow是一種非常靈活的開(kāi)發(fā)方式。對(duì)于一些規(guī)模比較大的團(tuán)隊(duì)，最好就是給特定的分支賦予不同的角色。除了功能分支(feature branch)，Gitflow Workflow還使用獨(dú)立的分支來(lái)準(zhǔn)備發(fā)布(preparing)，維護(hù)(maintaining), 和記錄版本(recording releases)。

下圖能說(shuō)明整個(gè)流程，只要你看得懂的話。該模式來(lái)自 Nvie

feature（多個(gè)、玫紅）。主要是自己玩了，差不多的時(shí)候要合并回develop去。從不與master交互。

develop（1個(gè)、黃色）。主要是和feature以及release交互。

release（同一時(shí)間1個(gè)、綠色）?？偸腔赿evelop，最后又合并回develop。當(dāng)然對(duì)應(yīng)的tag跑到master這邊去了。生命周期很短，只是為了發(fā)布

hotfix（同一時(shí)間1個(gè)、紅色）。總是基于master，并最后合并到master和develop。生命周期較短，用了修復(fù)bug或小粒度修改發(fā)布。

master（1個(gè)藍(lán)色）。沒(méi)有什么東西，僅是一些關(guān)聯(lián)的tag，因從不在master上開(kāi)發(fā)。

在這個(gè)模型中，master和develop都具有象征意義。master分支上的代碼總是穩(wěn)定的（stable build），隨時(shí)可以發(fā)布出去。develop上的代碼總是從feature上合并過(guò)來(lái)的，可以進(jìn)行Nightly Builds，但不直接在develop上進(jìn)行開(kāi)發(fā)。當(dāng)develop上的feature足夠多以至于可以進(jìn)行新版本的發(fā)布時(shí)，可以創(chuàng)建release分支。

release分支基于develop，進(jìn)行很簡(jiǎn)單的修改后就被合并到master，并打上tag，表示可以發(fā)布了。緊接著release將被合并到develop；此時(shí)develop可能往前跑了一段，出現(xiàn)合并沖突，需要手工解決沖突后再次合并。這步完成后就刪除release分支。

當(dāng)從已發(fā)布版本中發(fā)現(xiàn)bug要修復(fù)時(shí)，就應(yīng)用到hotfix分支了。hotfix基于master分支，完成bug修復(fù)或緊急修改后，要merge回master，打上一個(gè)新的tag，并merge回develop，刪除hotfix分支。

由此可見(jiàn)release和hotfix的生命周期都較短，master/develop雖然總是存在但卻不常使用。

主分支是所有開(kāi)發(fā)活動(dòng)的核心分支。所有的開(kāi)發(fā)活動(dòng)產(chǎn)生的輸出物最終都會(huì)反映到主分支的代碼中。主分支分為master分支和development分支。

master 分支

master分支上存放的應(yīng)該是隨時(shí)可供在生產(chǎn)環(huán)境中部署的代碼（Production Ready state）。當(dāng)開(kāi)發(fā)活動(dòng)告一段落，產(chǎn)生了一份新的可供部署的代碼時(shí)，master分支上的代碼會(huì)被更新。同時(shí)，每一次更新，最好添加對(duì)應(yīng)的版本號(hào)標(biāo)簽（TAG）。

develop分支

develop分支是保存當(dāng)前最新開(kāi)發(fā)成果的分支。通常這個(gè)分支上的代碼也是可進(jìn)行每日夜間發(fā)布的代碼（Nightly build）。因此這個(gè)分支有時(shí)也可以被稱作整合分支（integration branch）。

輔助分支是用于組織解決特定問(wèn)題的各種軟件開(kāi)發(fā)活動(dòng)的分支。輔助分支主要用于組織軟件新功能的并行開(kāi)發(fā)、簡(jiǎn)化新功能開(kāi)發(fā)代碼的跟蹤、輔助完成版本發(fā)布工作以及對(duì)生產(chǎn)代碼的缺陷進(jìn)行緊急修復(fù)工作。這些分支與主分支不同，通常只會(huì)在有限的時(shí)間范圍內(nèi)存在。

輔助分支包括：

用于開(kāi)發(fā)新功能時(shí)所使用的feature分支；

用于輔助版本發(fā)布的release分支；

用于修正生產(chǎn)代碼中的缺陷的hotfix分支。

以上這些分支都有固定的使用目的和分支操作限制。從單純技術(shù)的角度說(shuō)，這些分支與Git其他分支并沒(méi)有什么區(qū)別，但通過(guò)命名，我們定義了使用這些分支的方法。

使用規(guī)范：

可以從develop分支發(fā)起feature分支

代碼必須合并回develop分支

feature分支的命名可以使用除master，develop，release-*，hotfix-*之外的任何名稱

feature分支（有時(shí)也可以被叫做“topic分支”）通常是在開(kāi)發(fā)一項(xiàng)新的軟件功能的時(shí)候使用，這個(gè)分支上的代碼變更最終合并回develop分支或者干脆被拋棄掉（例如實(shí)驗(yàn)性且效果不好的代碼變更）。

使用規(guī)范：

可以從develop分支派生

必須合并回develop分支和master分支

分支命名慣例：release-*

release分支是為發(fā)布新的產(chǎn)品版本而設(shè)計(jì)的。在這個(gè)分支上的代碼允許做小的缺陷修正、準(zhǔn)備發(fā)布版本所需的各項(xiàng)說(shuō)明信息（版本號(hào)、發(fā)布時(shí)間、編譯時(shí)間等等）。通過(guò)在release分支上進(jìn)行這些工作可以讓develop分支空閑出來(lái)以接受新的feature分支上的代碼提交，進(jìn)入新的軟件開(kāi)發(fā)迭代周期。

當(dāng)develop分支上的代碼已經(jīng)包含了所有即將發(fā)布的版本中所計(jì)劃包含的軟件功能，并且已通過(guò)所有測(cè)試時(shí)，我們就可以考慮準(zhǔn)備創(chuàng)建release分支了。而所有在當(dāng)前即將發(fā)布的版本之外的業(yè)務(wù)需求一定要確保不能混到release分支之內(nèi)（避免由此引入一些不可控的系統(tǒng)缺陷）。

成功的派生了release分支，并被賦予版本號(hào)之后，develop分支就可以為“下一個(gè)版本”服務(wù)了。所謂的“下一個(gè)版本”是在當(dāng)前即將發(fā)布的版本之后發(fā)布的版本。版本號(hào)的命名可以依據(jù)項(xiàng)目定義的版本號(hào)命名規(guī)則進(jìn)行。

使用規(guī)范：

可以從master分支派生

必須合并回master分支和develop分支

分支命名慣例：hotfix-*

除了是計(jì)劃外創(chuàng)建的以外，hotfix分支與release分支十分相似：都可以產(chǎn)生一個(gè)新的可供在生產(chǎn)環(huán)境部署的軟件版本。

當(dāng)生產(chǎn)環(huán)境中的軟件遇到了異常情況或者發(fā)現(xiàn)了嚴(yán)重到必須立即修復(fù)的軟件缺陷的時(shí)候，就需要從master分支上指定的TAG版本派生hotfix分支來(lái)組織代碼的緊急修復(fù)工作。

這樣做的顯而易見(jiàn)的好處是不會(huì)打斷正在進(jìn)行的develop分支的開(kāi)發(fā)工作，能夠讓團(tuán)隊(duì)中負(fù)責(zé)新功能開(kāi)發(fā)的人與負(fù)責(zé)代碼緊急修復(fù)的人并行的開(kāi)展工作。

多個(gè)Feature 分支開(kāi)發(fā)完成，提交到develop 分支時(shí)，修改了共同的模塊。

release 分支或者h(yuǎn)otfix 分支修改了bug合并回develop時(shí)，發(fā)現(xiàn)develop分支已經(jīng)往前面走了一截。

在執(zhí)行可能有沖突的操作前，先查看一下?暫存區(qū)?和?工作目錄，保證其中沒(méi)有修改。

比如使用git stash就可以把暫存區(qū)?和?工作目錄的修改保存起來(lái)，讓暫存區(qū)?和?工作目錄處于干凈的狀態(tài)。

Gitflow workflow 和pull request 組合起來(lái)使用，代碼審查機(jī)制的加入，會(huì)讓這個(gè)模式大放異彩。下一篇文章中， 我會(huì)詳細(xì)介紹 代碼審查????。

Forking Workflow與以上討論的工作流很不同，一個(gè)很重要的區(qū)別就是它不只是多個(gè)開(kāi)發(fā)共享一個(gè)遠(yuǎn)程倉(cāng)庫(kù)(central repository)，而是每個(gè)開(kāi)發(fā)者都擁有一個(gè)獨(dú)立的服務(wù)端倉(cāng)庫(kù)。也就是說(shuō)每個(gè)contributor都有兩個(gè)倉(cāng)庫(kù)：本地私有的倉(cāng)庫(kù)和遠(yuǎn)程共享的倉(cāng)庫(kù)。

Forking Workflow

Forking Workflow這種工作流主要好處就是每個(gè)開(kāi)發(fā)者都擁有自己的遠(yuǎn)程倉(cāng)庫(kù)，可以將提交的commits推送到自己的遠(yuǎn)程倉(cāng)庫(kù)，但只有工程維護(hù)者才有權(quán)限push提交的commits到官方的倉(cāng)庫(kù)，其他開(kāi)發(fā)者在沒(méi)有授權(quán)的情況下不能push。Github很多開(kāi)源項(xiàng)目都是采用Forking Workflow工作流。

Git版本控制與工作流

基于git的源代碼管理模型——git flow