GitFlow在实际中使用的摸索
网上介绍Git Flow的博客非常多,本文参考了网上的资料,结合自己以往使用Git中的一些心得体会和思考,重新总结和归纳,最重要的是附带一个带有场景的实际的例子,去演示Git Flow在实际的开发中,要如何用。当然受限于作者的知识和能力,也会有考虑不周,或待改进的地方。
建议
我们的开发流程,一定要有版本的概念,每次发布,都要有版本号,即使是bug修复,也要有版本号。每个版本号,更新了什么功能,修复了什么bug,都是要记录清楚的,这样管理就会变得可控和简易。切记不要小作坊的思维模式,“随意上线”,"随时上线"的状态,这样会导致相关人员疲于奔命应付,导致流程相当难管理。上线了,即使线上有bug,只要不是严重的,都应该忽视,等在下一个版本里进行修复。这样开发人员、测试人员、产品人员等等才会有更多的精力投入到下一个版本的工作中。
一定要认识到,发布是一个流程,有前期的需求调研、原型的设计、UI的设计、编码、测试、环境准备和部署等等流程组成。切记不可低估和省略测试环节,草草测试,草草上线,只会让整个流程陷入泥潭,使各方人员陷入疲于应付的状态,从而变成恶性循环。
概述
Git Flow中master和develop分支是长期存在的,它们是主要的分支。release、hotfix、feature是临时分支,是辅助性的分支,在某个时候会删掉。
注意:develop分支有时简写为dev,hotfix有时也会用bugfix或fixbug,反正不管怎么叫,其作用是固定的。
详细解释各分支
-
master
用于记录上线的历史版本。每次上线后,都会将所上线的代码记录在此分支,并打上版本tag。(长期分支)
-
develop
用来记录开发(编码)的主线,用来合并各个开发人员协作开发的各种功能特性(feature)。(长期分支)
-
hotfix
临时从master中拉出来的分支,用于紧急解决线上的bug,上线修复后必须合并到master和develop,并且删除该分支。(短期分支,用完就删)
-
release
上线用的就是该分支,待开发组长把各feature分支合并到develop后,由develop拉出release分支,供QA部署测试线并进行测试。上线后将release合并到master并在master打上版本号tag,然后删除该分支。(短期分支)
-
feature
用于开发某个特性(功能)的分支。
详细流程,详细例子
假设有A、B、C三个开发,A是组长。目前线上的版本是v1.0.0,现在要开发v2.0.0版本。目前git仓库中有master分支和develop分支,其他分支因为是临时分支,都删除了。
-
A、B、C分别从develop分支拉出feature分支,在各自的分支上进行开发,具体feature分支名:feature_v2.0.0_a、feature_v2.0.0_b、feature_v2.0.0_c (*注意)
-
最后开发好后,只有组长A有权限将feature_xxx分支合并到develop里。合并好后通知QA可测。
-
QA从develop拉出release分支,QA基于release分支进行测试(注意:这里只有QA才有权限从develop拉出release分支,避免在QA测试期间开发人员可以随意往release分支推代码)
-
QA发现有bug,假如由C进行修复,由C在feature_v2.0.0_c进行修复,然后再由组长A再次合并到develop里并通知QA已经修复
-
QA将develop分支合并到release里,并验证bug是否修复。如果未修复或还有bug,重复流程1. 直至认为测试完成。QA通知运维发布。
-
运维用release分支的代码里打包发布。
-
发布完成。
-
运维将release分支的代码合并到master,并打上v2.0.0标签,删除release分支。
-
发现线上bug,项目负责人评估是小bug,暂不修复!!!(小bug不影响的不要处理,待下个版本处理,否则会被拖入泥潭)
-
调研v3.0.0功能,讨论需求,原型设计,UI设计,准备开始编码工作
-
A、B、C,从develop拉出feature_v3.0.0_a、feature_v3.0.0_b、feature_v3.0.0_c分支,删除feature_v2.0.0_a、feature_v2.0.0_b、feature_v2.0.0_c分支。(**注意)
-
A、B、C三人赶进度开发v3.0.0需求
-
发现线上bug(此时线上版本是v2.0.0),项目负责人评估是大bug,得紧急修复
-
运维从master分支的v2.0.0的tag里拉出hotfix分支
-
A、B、C三人从hotfix拉出hotfix_a、hotfix_b、hotfix_c
-
待bug修复后,A组长负责把hotfix_a、hotfix_b、hotfix_c合并到hotfix,并通知QA进行验证
-
QA在hotfix的基础上打包部署测试环境并进行测试,测试有问题则重复流程,直至认为测试完成。QA通知运维发布。
-
运维用hotfix的代码打包发布
-
发布完成,bug已修复
-
运维将hotfix分支的代码合并到master,并打上v2.0.1的tag,合并hotfix到develop以便下次上线包含了缺陷修复(也可通知A去合并),运维删除hotfix
-
A、B、C继续开发v3.0.0的功能
注意:
- 关于feature系列的分支的命名,其实相对来说比较宽松,约束规则较少,例如:假如ad广告模块功能需要由2个人来完成,可以feature_v2.0.0_ad_a、feature_v2.0.0_ad_b,而c去做活动模块,可以用feature_v2.0.0_activity_c也可以更随意feature_v2.0.0_c。甚至,直接不用指定v2.0.0了,因为v1.0.0在上线后就删掉了,直接用feature_a、feature_b、feature_c也行。
- 什么时机删除旧的、已经上线了的feature分支(如feature_v2.0.0_a、feature_v2.0.0_b、feature_v2.0.0_c),这个其实没有严格的要求,其实可以在上线后就删除。
关于数据库版本的思考
这样子做好不好
上线了v2.0.0将开发库复制一份v3.0.0的,用于开发新版本。例如rms-back_dev_v2备份出rms-back_dev_v3,v3版用于开发新功能,当线上有bug的时候可以连回v2进行调试。
个人观点
如果是小系统小库,备份并不麻烦且很快速。这么做还是比较好的,因为保留了一份跟线上数据库一致的数据库。
反对的声音:
有人可能会说,不备份rms-back_dev_v2也行呀,假设线上有bug,从QA测试的库rms-back_test中复制一份用于改bug即可。
答:
-
开发库可能存在配置数据,跟测试库的不一样,既然备份如此容易,何不备份上线新版后备份开发库? 2、小团队甚至没有测试库,直接由研发进行测试后上线。
-
如果是大的系统,备份并不现实,尤其是库多、数据多的情况下。这时候该怎么办? 开发库库表被改成了新版,但线上又有bug。这时候由具体某个负责的开发自行去想办法,例如可以想办法还原(从测试库还原等),况且对于大型公司,每个人负责一小块,难道作为开发还记不住自己改了哪些库表?难道还还原不回去?况且对于稳定的系统,频繁、不兼容式的改库表不会是常态。