gitflow的分支型別：

• master分支（1個）
• develop分支（1個）
• feature分支。同時存在多個。
• release分支。同一時間只有1個，生命週期很短，只是為了釋出。
• hotfix分支。同一時間只有1個。生命週期較短，用了修復bug或小粒度修改釋出。

在這個模型中，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雖然總是存在但卻不常使用。

以上就是gitflow的基本概念了。下面是nvie（gitflow的提出者，一個荷蘭人！） A successful Git branching model（釋出於2010年月5日）一文的筆記。

從右看起：

• 時間軸。
• feature（玫紅）。主要是自己玩了，差不多的時候要合併回develop去。從不與master互動。
• develop（黃色）。主要是和feature以及release互動。
• release（綠色）。總是基於develop，最後又合併回develop。當然對應的tag跑到master這邊去了。
• hotfix（紅色）。總是基於master，並最後合併到master和develop。
• master（藍色）。沒有什麼東西，僅是一些關聯的tag，因從不在master上開發。

接下來nvie說道自己喜愛git，因git改變了人們對合並/分支（merge/branches）的看法。從集中式的程式碼管理工具過來的人感到釋放了（beware of merge conflicts, they bite you，注意合併衝突，它們會跳出來咬你！）。

gitflow例項

安裝gitflow：

$ git clone --recursive git://github.com/nvie/gitflow.git
$ cd gitflow/
$ sudo make install
$ ls /usr/local/bin/git-flow
/usr/local/bin/git-flow

到專案根目錄下執行gitflow，因為之前修改沒有commit，所以gitflow初始化失敗：

$ git flow init
fatal: Working tree contains unstaged changes. Aborting.

commit後再次進行gitflow初始化：

$ git commit -a -m "update Bash"
[master 8f5b874] update Bash
 4 files changed, 71 insertions(+), 5 deletions(-)

[[email protected] zhuji]$ git flow init

Which branch should be used for bringing forth production releases?
   - master
Branch name for production releases: [master] 
Branch name for "next release" development: [develop] 

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 

一路回車下來，各個分支名都按預設的設定。最後，當前分支已經被切換到了develop：

$ git branch
* develop
  master

建立一個新的feature。git flow新建了功能分支feature/blog_builder，並在develop的基礎上checkout了新分支：

$ git flow feature start blog_builder
$ git branch
  develop
* feature/blog_builder
  master

開發完成後執行如下命令：

$ git flow feature finish blog_builder
Summary of actions:
- The feature branch 'feature/blog_builder' was merged into 'develop'
- Feature branch 'feature/blog_builder' has been removed
- You are now on branch 'develop'

正如這條命令的總結所言，git flow為我們做了3件事：

• 把feature/blog_builder合併到了develop。
• 刪除了feature/blog_builder分支。
• 切換回develop分支。

接下來發佈一個正常的版本：

$ git flow release start v0.5

一旦需要釋出的版本確認無誤可以釋出後，執行命令：

$ git flow release finish v0.5
summary of actions:
- Latest objects have been fetched from 'origin'
- Release branch has been merged into 'master'
- The release was tagged 'v0.5'
- Release branch has been back-merged into 'develop'
- Release branch 'release/v0.5' has been deleted

注意release/v0.5被合併到了master和develop分支，並打了個v0.5的tag，然後被刪除，最後切換回了develop分支：

$ git branch
* develop
  master

釋出時只需將tag為v0.5的版本checkout出來部署即可：

$ git tag
v0.5

當上線後發現v0.5的bug，可以進行hotfix：

$ git flow hotfix start v0.5.1

此時gitflow從master分支上拉出一個hotfix/v0.5.1的分支，接下來在新分支上修改bug。最後執行命令：

$ git flow hotfix finish v0.5.1

這樣hotfix/v0.5.1被merge到master/develop分支，打好v0.5.1這個tag，刪除這個分支，切換回develop分支。

之後又是新一次的輪迴，啟動正常的feature開發。

參考文獻：