阅读 368

git的分支管理

1. 分支管理策略

前端采用Git Flow的分支策略,即为功能分支策略。以下为理想的分支管理策略,实际分支管理情况,由各个组长确定。相应分支功能说明如下:

1.1 master分支

主分支,该分支上的代码,已经经过测试,并且无bug,可以直接发版的分支。

分支合并情况:

合并分支:test分支测试完成后,合并到master分支上。

打tag(后端处理):要发版的时候,后端会从master分支上拉取代码,拉取前,他们会在master分支上打一个tag。表明现在线上拉取的是这个节点代码。

1.2 test(release)分支

测试分支(对应gitflow的预发布分支),根据测试环境和测试功能的不同可能会有test、test2、test3……等多个分支。测试分支是发布到测试环境或者灰度环境的分支。测试同事会测试上面的代码,确保代码没有问题。测试通过后,在发版前,需要把测试分支的代码合并到master分支上。

测试分支上有bug,有两种处理方案。1是直接在test分支上改,2是从test分支上拉取新的分支hotfix_testX(x为分支序号)_xxx(xxx为bug名),在此分支上改。在新分支上,修改bug后再合并会test分支上。

分支合并情况:

拉取分支:从最新的tag上重新拉取testX分支。这样就可以保证testX分支上代码跟线上的代码一致。

合并分支:拉取新的test分支后,把feature分支合并到testX分支上,发版,发版后通知测试同事测试。

上线:testX分支测试通过后,再合并到master分支。保证新功能上线。

删除分支:test分支合并完了,删除test分支(本地,远程都删除)。

目前小药药test分支,命名没有语义化,命名是test、test2、test3。每一个分支,对应什么测试环境、什么测试功能并不明确。用到时可以问下开发。

1.3 feature分支

模块功能分支,有时候我们同一个系统,经常有多个功能同时开发的情况。因此我们需要根据不同的功能,拉取不同的分支。feature分支由组长从最新的tag上拉取,保证feature分支跟线上的一致。

feature分支命名feature-xxx(xxx为新的功能)。

feature分支拉取完成后,可以直接在该分支上开发,也可以每个人从feature分支上拉取一个自己的分支,比如feature-xxx-gxq,开发完成后再合并到feature分支上。

功能可以提测的时候,再把feature分支合并到testX分支上,给开发测试。

分支合并情况:

拉取分支:新功能拉取新的分支,feature分支从最新的tag上拉取,各个开发可以在feature分支上直接开发,也可以拉取自己的分支,开发完成之后再合并上去。

合并分支:功能开发完成后再把feature分支合并testX分支上。

删除分支:合并分支后,删除feature分支(本地,远程一起删)。

1.4 hotfix分支

hotfix为正式线的补丁分支,当线上代码有bug的时候,需要从最新的tag上拉取一个分支来修复bug。这个分支命名通常为hotfix-xxx(xxx为bug名)。

开发在hotfix上修改bug后。拉取一个新的test分支。如果要拉取的分支名已经存在,问下开发这个分支有没有人使用,没有的话,就删除该分支。从最新tag上拉取一个test分支,把你的hotfix分支合并到test分支,测试通过后。再把test分支合并到master分支上,同时还要把你没有问题的hotfix分支,合并到其他所有的test分支上和feature分支上。

分支合并情况:

拉取分支:从最新的tag上拉取分支

合并分支:先是合并到test分支,拿去测试。测试通过后,再合并到所有的test和feature分支上。避免这些分支再合并到master上时,把以前修改过的代码,又修改回来了。

1.5 tag说明

在重要的节点,要给分支打个tag,这样万一出现问题时,方便及时回滚。

1.6 其他分支

除了以上所说的那些分支外,还有些其他分支,比如bench(压测)分支。这些分支一般都是从最新的tag上拉取的。当你需要更新这些分支的时候,建议直接把这个分支删了,重新从最新的tag上拉取。如果担心有意外发生,可以咨询下开发。

另外gitflow中还推荐一个分支develop分支,我们根据我们实际开发需要,不再单独建develop分支。把master分支当develop分支使用,这样可以减少些流程上的麻烦。

2.分支的命名

我们拉分支的时候,不仅要知道分支是什么功能,还需要知道分支从哪里来,那一天建立,由于分支不能加备注说明,因为我们只能在分支命名上加以体现。

分支命名规则如下:

功能-模块-来源-日期

比如saas项目,修改线上灰度会员bug的分支,就可以命名如下:

hotfix(功能)-member(模块)-master(来源)-1111(日期)

3.几个需要谨记的点

1.一旦分支已经上线或者上灰度,就不能在原来的分支上改bug。改bug必须重新拉分支。避免,master上合并的修改别冲掉。

2.回滚不能使用revert命令,而是要尽量使用reset。避免回滚之后,再合并时合并不上。

3.mergeRequest的时候,出现冲突,一定不能在gitlab上解决。gitlab上解决冲突会导致双向merge,把合并分支上的功能合并到feature分支上。

关注下面的标签,发现更多相似文章
评论