GIT操作规范-Git Flow(上)之介绍

我们使用Git作为版本控制工具,在使用Git的过程中就需要有规范,我们先来了解Git Flow

Git Flow 是什么

Git Flow是构建在Git之上的一个组织软件开发活动的模型,是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具。

Git Flow是由nvie提出的,博文地址:

URL: A successful Gitbranching model

PDF: http://nvie.com/files/Git-branching-model.pdf

中文介绍: Git工作流指南:Gitflow工作流

Git Flow中的分支

主分支

开发过程中的核心分支,所有的开发记录都会在主分支体现,主分支包含两个分支:

  • master
  • develop
GIT操作规范-Git Flow(上)之介绍_第1张图片

master分支

master分支上的代码是可以随时发布到生存环境中的代码(production-ready),每次提交到master的代码都必须打上标签标示版本号。

develop分支

我们称为开发分支,又称集成分支(integration branch),辅助分支完成自己的开发之后都会合并到develop分支,确定要把当前已经集成的功能发布一个版本的时候,就需要把devlop分支合并到master分支(下面会介绍中间其实还有一个release分支),并打上带版本号的标签。

辅助分支

辅助分支也是开发人员主要使用的分支,辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工作以及对生产代码的紧急修复工作。与主分支不同,辅助分支通常只会在有限的时间范围内存在,完成辅助分支的使命后一般会被删除。

辅助分支包括:

  • feature分支
  • release分支
  • hotfix分支
feature分支

GIT操作规范-Git Flow(上)之介绍_第2张图片

当我们需要开发一个新功能的时候就需要从devlop分支创建一个新分支,命名“feature/*”(*希望能比较直观反映这个功能),这个功能得开发成员就可以再这个分支上进行开发,多个新功能可以并行开发而互补影响。开发完成并自测通过之后将此分支合并到develop分支,合并之后这个feature分支的生命周期也就结束了,删除掉feature分支

release分支

某些功能完成之后合并到devlop分支了,测试也通过了,我们决定发布一个版本了,这时候我们从develop分支创建一个新分支,命名“release/*”(*一般使用版本号)。

release分支创建之后,下一个版本需要发布的功能分支就可以合并到develop分支了(这样就不会因为下一版的功能分支合并到develop导致不能正常发布、也不会因为需要发版所以其他功能分支在发版之前都不能合并到develop分支)。

在release分支上的代码还可以进行测试和修复问题(只允许做bug修复,不允许开发新功能),修复之后合并到master分支的同时也需要合并到develop分支(好的习惯是修复过程中持续合并到develop分支),接着删除release分支。

hotfix分支


GIT操作规范-Git Flow(上)之介绍_第3张图片

生产环境遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候怎么办?develop分支上可能已经有了一个版本的功能,所以不可能等develop上修复了发布下一个版本。那么我们就需要从master分支上指定的版本新建hotfix分支来做紧急修复工作。命名“hotfix/*”(*一般使用版本号)

修复完成之后我们合并回master分支并打上标签, 同时合并到develop分支,如果这时候我们有release分支,也需要合并到release分支



下一篇将介绍 flow的实际操作 

你可能感兴趣的:(操作规范)