Git作为分布式代码管理的“当红炸子鸡”,被越来越多团队使用。当团队多个人员在同一个Git仓库上进行代码开发,没有一套标准化流程,将会引起代码管理的混乱,上线流程的迷茫,影响工作效率。制定一套适合自己团队的Gitflow标准化工作流势在必行!
写在前面的话
Git,作为分布式代码管理软件中的“当红炸子鸡”,被越来越多的开发人员在使用,也被越来越多的开发人员在赞美,是因为它杰出的“分布式”特性,大大方便了团队人员间互相合作。我们火锅管理系统最近也采用Git作为我们代码的管理软件。看着大家每天在Git仓库上建分支,拉代码,合代码,干得不亦乐乎,甚是感染。但是,分支一多,参与人员对Git的掌握程度不一致,难免会出现分支代码管理混乱,上线流程不清晰,从而影响开发效率。正所谓,有规则圆,有矩则方,没有规矩难成方圆。这就是为啥我们需要把Git工作流进行标准化处理,统一的拉分支规则,统一的上线流程,让整个团队所有人员按照统一的标准来干活,从而提高我们代码管理及其上线的效率。
目前的GIT Flow工作流
对Git工作流进行标准化处理咋们可并不是第一家。目前已经有很多人对Git工作流的标准化进行过处理。大概有以下几种:功能开发工作流,Gitflow工作流,Forking工作流,GitHub工作流等。下面我们主要介绍Gitflow工作流。
Git Flow工作流
Gitflow工作流是目前非常流行的一种比较成熟的工作流。该工作流的具体实例图形如下图所示。
如上图所示,我们可以看到,Gitflow工作流把整个代码分支分成了以下几种:Master分支,Hotfix分支,Release分支,Develop分支,Feature分支。各个分支的作用及其交互为:
Feature分支:我们每当要迭代一个新功能,就需要来创建一个feature分支。该功能的所有代码都在该feature分支上维护。feature分支代码从Develop分支上拉取;并且,代码也会push回Develop分支;
Develop分支:是我们的开发分支。所有的开发人员在一个迭代周期中,都是从develop分支去拉取代码,然后功能开发完成,就check in回develop分支。当某个迭代周期完成,我们需要从develop分支上把可以发布上线的功能拉取到Release分支进行上线;
Release分支:当一个迭代周期完成,我们需要从develop分支拉取可以上线的功能到release分支。一旦release分支拉取功能确定,在上线之前,任何人都不可以再往release分支上提交代码。在release分支上进行提测,上线后,合并到master分支;
Master分支:对应上线功能的代码版本,它是最稳定的代码分支。
HotFix分支:如果线上系统出现了bug,我们需要从master分支拉取一个新分支,也就是hotfix分支,在该分支上解决bug,并且校验bug,然后从该分支上线;
腾讯很多的团队都在采用Gitflow工作流。我们团队也想直接采用Gitflow工作流严格执行,但是我们团队有我们团队的特点,比如,我们没有一个固定的迭代周期,每个功能是直接分配给某一个人来单独开发,单独估计开发时间,单独上线,并且迭代周期很短;前端和后台的代码不在同一个Git仓库中来管理,是分开管理的。以上原因,导致如果我们严格采用Gitflow工作流,有些分支并不需要,有些冗余。针对以上情况,经过小组讨论,我们把gitflow工作流根据自己组的特定情况,更改为如下流程:具体如下图所示:
由于我们没有整体迭代周期的概率,每个功能都是分配给每个具体的人员,由每个具体的人员来分别估计工作时间,并单独开发,然后单独上线,所以,我们去掉了develop分支和release分支,但是增加了merge request过程来做代码review。具体流程如下:
1)开发人员接到一个新功能需求开发,从master上拉取一个新功能分支,命名规则为:feature-XXX,其中,XXX为功能模块的名字,尽量通俗易懂;
2)在本地Git仓库也创建一个feature-XXX分支,对应远程的feature-XXX分支。开发人员就在本地的feature-XXX分支上进行功能的开发;
3)当功能开发完成,需要进行提测,提测之前,跟master分支进行一次代码合并,然后Push代码到远程的feature-XXX分支,在该分支上进行提测,上测试机,并进行问题的修复;
4)当测试完成,进行预发布测试,从feature-XXX分支拉代码部署到预发布机,在线上环境进行校验,并进行问题的修复;
5)预发布测试完成,开始提交merge request,做code review。然后,将代码从feature-XXX合并到master分支。
6)从master分支将代码部署到灰度机器进行灰度,灰度完成没有问题,直接全量;发现问题,回退代码,到步骤5)重新进行;
7)如果发现线上系统有bug,需要从master分支直接拉取一个bug fixing分支,在该分支上做bug fixing。bug fixing分支的命名规则:bugfixing-XXX-YYY,其中,XXX为功能名称,YYY为分支创建日期。例如:bugfixing-imageurl-0821。所有问题,都在bug fixing分支上修改,并且提测,预发布。当问题解决,准备上线,同理,提交一个merge request,做code review。然后合并代码回Master。在master分支上灰度,并全量上线;
8)功能全量上线后,对应的分支即可删除。
9)尽量不要重复用同一个分支来进行多个不同功能的开发,这样很容易让人引起误解。
写在后面的话
没有放之四海而皆准的真理,也没有完美无瑕的流程,只有适合自己团队的流程,才是合理的好流程。在上面流程中,我们没有固定的迭代周期,故而我们去掉了develop分支和release分支。但是,一旦我们的开发流程发生了改变,工作模式发生了变化,那么我们的Gitflow工作流也会随之进行调整。