gitflow分支管理模型

2022年05月13日 阅读数:2
这篇文章主要向大家介绍gitflow分支管理模型,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。


gitflow的分支类型:git

  • master分支(1个)
  • develop分支(1个)
  • feature分支。同时存在多个。
  • release分支。同一时间只有1个,生命周期很短,只是为了发布。
  • hotfix分支。同一时间只有1个。生命周期较短,用了修复bug或小粒度修改发布。

在这个模型中,master和develop都具备象征意义。master分支上的代码老是稳定的(stable build),随时能够发布出去。develop上的代码老是从feature上合并过来的,能够进行Nightly Builds,但不直接在develop上进行开发。当develop上的feature足够多以致于能够进行新版本的发布时,能够建立release分支。github

release分支基于develop,进行很简单的修改后就被合并到master,并打上tag,表示能够发布了。紧接着release将被合并到develop;此时develop可能往前跑了一段,出现合并冲突,须要手工解决冲突后再次合并。这步完成后就删除release分支。ide

当从已发布版本中发现bug要修复时,就应用到hotfix分支了。hotfix基于master分支,完成bug修复或紧急修改后,要merge回master,打上一个新的tag,并merge回develop,删除hotfix分支。工具

因而可知release和hotfix的生命周期都较短,master/develop虽然老是存在但却不常使用。post

以上就是gitflow的基本概念了。下面是nvie(gitflow的提出者,一个荷兰人!) ​​A successful Git branching model​​(发布于2010年月5日)一文的笔记。fetch

gitflow分支管理模型_git

从右看起:ui

  • 时间轴。
  • 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,注意合并冲突,它们会跳出来咬你!)。code

gitflow实例

安装gitflow:blog

$ 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(-)

[bailing@zhuji 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开发。