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 Bash4 files changed, 71 insertions(+), 5 deletions(-)[bailing@zhuji zhuji]$ git flow initWhich 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
* developmaster

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

$ git flow feature start blog_builder
$ git branchdevelop
* feature/blog_buildermaster

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

$ 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
* developmaster

發布時只需將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開發。

總結

以上是生活随笔為你收集整理的gitflow分支管理模型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。