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分支管理模型相关推荐

GitFlow 代码管理模型实战
GitFlow 代码管理模型实战一概述 Git Flow定义了一个项目发布的分支模型,为管理具有预定发布周期的大型项目提供了一个健壮的框架. master分支存放所有正式发布的版本,可以作为项目历 ...
Git、GitHub、GitLab Flow，傻傻分不清？一图看懂各种分支管理模型
理论是灰色的,生命之树常青. 引言任何一家公司乃至于一个小组织,只要有写代码的地方,就有代码版本管理的主场,初入职场,总会遇到第一个拦路虎 git 管理流程,但是每一个企业似乎都有自己的 git 管 ...
一文读懂Gitflow分支管理
1.1.分支说明 Git 的分支主要分为两个长期分支 master .develop :三个短期分支hotfix .release.feature 两个长期分支 master分支:主干分支,用于存储正 ...
Gitflow分支管理策略
Gitflow存在两个记录项目历史的分支 Master分支:存储(官方的,正式的)项目发布历史记录的分支. develop分支:充当功能的集成分支. Develop分支将包含项目的完整历史记录,而ma ...
详解Gitflow分支管理策略
Gitflow存在两个记录项目历史的分支 Master分支:存储(官方的,正式的)项目发布历史记录的分支. develop分支:充当功能的集成分支. Develop分支将包含项目的完整历史记录,而ma ...
svn合并分支到主干_谈谈代码分支管理
前言从2019年上半年云音乐的客户端团队开始迁移到双周迭代后,随之而来的是我们需要重新调整代码分支的管理方法,来应对开发流程的变更. 双周迭代顾名思义一周开发一周测试,目的就是为了快速交付.纵观整个 ...
Git Flow分支管理
1.Sourcetree简介及安装一个用于Windows和Mac的免费Git客户端.Sourcetree简化了如何与Git存储库进行交互,这样您就可以集中精力编写代码.通过Sourcetree的简单 ...
版本分支管理标准 - Trunk Based Development 主干开发模型
之前分享过<版本分支管理标准 - Git Flow>,不过在实际使用过程中, 因为其有一定的复杂度,使用起来较为繁琐,所以一些人员较少的团队并不会使用这个方案. 在这基础上,一些新的分支管 ...
Gitflow 分支详解
1.gitflow 介绍比如我很喜欢的git stash命令,可以把当前没有完成的事先暂存一下,然后去忙别的事.git cherry-pick命令可以让你有选择地合并提交.git add -p可以 ...

gitflow分支管理模型

gitflow实例

gitflow分支管理模型相关推荐

最新文章

热门文章