gitflow工作流

优点:
1.由于是分布式的,所有本地仓库包含了远程库的所有内容
2.优秀的分支模型,打分支以及合并分支,极其方便
3.快速,在现在时间就是金钱的时代,git由于代码都在本地,打分支和合并分支极其快速

版本管理的挑战
虽然有这么优秀的版本管理工具,但是我们面对版本管理的时候,依然有非常大的挑战,我们都知道大家工作在同一个仓库上,那么彼此的代码协作必然带来很多问题和挑战,如下:
1.如何开始一个Feature的开发,而不影响别的Feature?
2.由于很容易创建分支,分支多了如何管理,时间久了,如何知道每个分支是干什么的
3.哪些分支已经合并回到了主干?
4.如何进行Release的管理?开始一个Release的时候如何冻结Feature,如何在Prepare Release的时候,开发人员可以继续开发新的功能?
5.线上代码出Bug了,如何快速修复?而且修复的代码要包含到开发人员的分支以及下一个Release?

gitflow
为了解决上述问题,引出了gitflow

Production分支:也就是我们经常使用的Master分支,这个分支最近发布到生产环境的代码,最近发布的Release, 这个分支只能从其他分支合并,不能在这个分支直接修改
Develop分支:这个分支是我们是我们的主开发分支,包含所有要发布到下一个Release的代码,这个主要合并与其他分支,比如Feature分支
Feature分支:这个分支主要是用来开发一个新的功能,一旦开发完成,我们合并回Develop分支进入下一个Release
Release分支:当你需要一个发布一个新Release的时候,我们基于Develop分支创建一个Release分支,完成Release后,我们合并到Master和Develop分支
Hotfix分支:当我们在Production发现新的Bug时候,我们需要创建一个Hotfix, 完成Hotfix后,我们合并回Master和Develop分支,所以Hotfix的改动会进入下一个Release

短期分支:
feature,功能开发分支,用于承接具体功能需求的开发:

  • 派生于develop
  • 合并于develop

hotfix,bug修复分支,用于解决线上运行环境发现的bug

  • 派生于master
  • 合并于master、develop

release,版本发布分支,用于完成发布准备的

  • 派生于develop
  • 合并于master、develop

这三类分支都是短期分支,针对他们的工作内容完成后,一般都要进行删除。工作内容完成的标识有两个:开发完成、合并完成,缺一不可。

gitflow使用:
1.直接命令行(麻烦,繁琐,不推荐)
2.Git flow工具(Git flow script)
3.Git flow可视化工具(SourceTree)

gitflow工具:

下载:brew install git-flow
github地址:https://github.com/nvie/gitflow
release完成后,先打tag:    git tag -a 1.7 -m ‘tag说明’

欢迎分享本文,转载请保留出处:前端ABC » gitflow工作流

分享到:更多 ()

发表评论 0