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

我說的以下流程，sourceTree等工具已經(jīng)完美的支持了，鼠標點兩下就完成了。簡直是完美。

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

下圖能說明整個流程，只要你看得懂的話。該模式來自 Nvie

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

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

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

hotfix（同一時間1個、紅色）?？偸腔趍aster，并最后合并到master和develop。生命周期較短，用了修復(fù)bug或小粒度修改發(fā)布。

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

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

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

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

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

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

master 分支

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

develop分支

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

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

輔助分支包括：

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

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

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

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

使用規(guī)范：

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

代碼必須合并回develop分支

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

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

使用規(guī)范：

可以從develop分支派生

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

分支命名慣例：release-*

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

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

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

使用規(guī)范：

可以從master分支派生

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

分支命名慣例：hotfix-*

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

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

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

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

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

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

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

Gitflow workflow 和pull request 組合起來使用，代碼審查機制的加入，會讓這個模式大放異彩。下一篇文章中， 我會詳細介紹 代碼審查????。

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

Forking Workflow

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

Git版本控制與工作流

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