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

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

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

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

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

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

release（同一時間1個、綠色）。總是基于develop，最后又合并回develop。當然對應的tag跑到master這邊去了。生命周期很短，只是為了發布

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

master（1個藍色）。沒有什么東西，僅是一些關聯的tag，因從不在master上開發。

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

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

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

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

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

master 分支

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

develop分支

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

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

輔助分支包括：

用于開發新功能時所使用的feature分支；

用于輔助版本發布的release分支；

用于修正生產代碼中的缺陷的hotfix分支。

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

使用規范：

可以從develop分支發起feature分支

代碼必須合并回develop分支

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

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

使用規范：

可以從develop分支派生

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

分支命名慣例：release-*

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

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

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

使用規范：

可以從master分支派生

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

分支命名慣例：hotfix-*

除了是計劃外創建的以外，hotfix分支與release分支十分相似：都可以產生一個新的可供在生產環境部署的軟件版本。

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

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

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

release 分支或者hotfix 分支修改了bug合并回develop時，發現develop分支已經往前面走了一截。

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

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

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

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

Forking Workflow

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

Git版本控制與工作流

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