基于 Git flow 的版本管理

Git 提交准则
除了源码相关的东西之外,其他build产生的东西(如:maven的target文件夹,.idea文件夹等),均不能提交进入源码仓库,添加到.gitignore文件中忽略掉。
撰写规范的提交说明。一份好的提交说明可以帮助协作者更轻松更有效地配合工作。
要严格按照我们指定的流程切换到指定分支,开发相应的功能。

Git fLow
在多组员,多项目等环境进行协同工作时,如果没有统一规范、统一流程,则会导致额外的工作量,甚至会做无用功。所以要减少版本冲突,减轻不必要的工作,就需要规范化的工作流程。Git Flow 是前人经过探索总结出来的一套Git分支管理规范和流程。
基于 Git flow 的版本管理_第1张图片

分支介绍

  • master 分支
    master 分支上保存生成环境发布版本的代码,这个分支不进行commit修改,只能从其它分支合并,并且每次合并都打上发布的版本号,如上图所示,v0.1是项目初始化
  • develop 分支
    develop 分支从master新建的一个分支,是我们的主开发分支,本分支包含下一个要发布的版本的所有代码。这个分支一般也不进行commit修改,主要从feature分支合并。
  • feature 分支
    feature分支都是从develop分支新建,主要用来开发新功能,每个功能新开一个feature,保证功能的独立性。
  • release 分支
    release 分支是用来打包测试使用,当要发布的功能都从相应的feature分支合并到develop分支上后,从develop分支新建release分支,如果测试过程中发现bug,在本分支上修复,确定后打包发布,同时合并到develop和master,打上标签保存。release 就可以删掉了,也可以选择不删掉此分支。
  • hotfix 分支
    hotfix是用来修复上线版本BUG使用,从master分支新建,如上图,从v0.1新建了一个hotfix,修复后合并到master和develop,并且打上相应标签。

Git flow 流程
了解了每个分支的作用和从哪个分支新建而来之后,我们就可以仔细说说上图的整个流程了,这个流程我们先忽略hotfix分支,hotfix流程可以看上面hotfix分支介绍的内容。为了便于说明,我加入了一些标识给每个commit点。
基于 Git flow 的版本管理_第2张图片

  1. 在master分支上初始化项目,加入.gitignore,产生master(1)
  2. 从master(1)新建develop分支,产生develop(1)
  3. 从develop(1)新建feature2分支
  4. 从develop(2)新建feature1分支
  5. feature1分支是第一个版本要开发的功能,在feature1(2)开发完毕,这个时候需要合并到develop分支,进入release阶段,合并后产生develop(4),这个时候就可以吧feature1分支删掉了
  6. 从develop(4)新建release分支,产生release(1),打包后给测试人员测试,然后修复测试出的bug,修复commit后产生release(2)
  7. 把release(2)打包发布1.0版本后,保存1.0版本到master,保证后面需要修复线上bug能快速找到源码。合并到develop分支,产生develop(5),合并到develop是为了保证下一个release版本包含release(2)那些代码。分别合并后,可以选择是否删掉release分支,如果不删,也不能再在此分支上进行后续开发,后续开发只能新建分支来完成
  8. 到此,一个完整的开发到发布的流程已完成,你可以继续下一个版本的开发,从develop(5)新建一个feature3分支

线上bug修复流程

当用户反馈系统有bug时,为了处理bug,需要从master中创建出保养分支;等到bug修复完成,需要合并回master。

  1. 创建hotfix分支
  2. 修改bug
  3. 完成修复,合并到master发布
  4. 打标签
  5. 合并到develop

关于版本号

版本格式:主版本号.次版本号.修订号,版本号递增规则如下:

  • 主版本号:当你做了不兼容的 API 修改
  • 次版本号:当你做了向下兼容的功能性新增
  • 修订号:当你做了向下兼容的问题修正。

先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸。
主版本号为零(0.y.z)的软件处于开发初始阶段,一切都可能随时被改变。
标准的版本号必须采用 XYZ 的格式,其中 X、Y 和 Z 为非负的整数,且禁止在数字前方补零。X 是主版本号、Y 是次版本号、而 Z 为修订号。每个元素必须以数值来递增。例如:1.9.1 -> 1.10.0 -> 1.11.0。

每次打标签后,建议将版本变更信息补充到项目wiki中。

你可能感兴趣的:(git,flow,GitLab,SourceTree,IDE)