版本流程之我见
写在前面
我们在入职新公司要做的最重要的事情之一就是要熟悉项目的开发上线流程。这对我们能否快速上手至关重要。
主要的流程分为三部分
- 正常的需求分析开发上线流程；
- 测试bug修复合并测试流程；
- 线上bug修改合并上线流程；
工具：git （PS：svn版本管理也可以参照此流程）
理想流程
顾名思义，就是我们收到需求之后先开发，然后提测，然后上线，业务验收，需求关闭，形成了一个完成的版本流程；
那么我们可以怎么来进行版本管理的?
首先我们将版本分成三个分支
- develop
- release
- master
下面介绍下各个分支的作用：
develop — 开发分支，我们日常的开发自测便在次分支上完成
release — 待发布分支/测试分支，测试在此分支上进行合并测试
master — 线上分支，线上代码运行在此分支上
所以理想流程，是来了一个需求我们在develop上开发，然后merge到release上进行提测，测试完成之后再从release分支merge至master分支发布线上。这里的例子是单需求串行开发的例子。
如果是多需求并行开发呢，这就需要我们根据不同的需求基于develop来拉取不同的分支，比如中台项目platform-1，platform-2等等，拉取不同的分支之后分别进行开发，再本地测试完成之后在合并到develop统一测试一遍完整流程，没问题之后通知测试merge到release分支提测，后续流程同上。
测试BUG修改
一名前辈曾经说过，要想写出没有bug的代码的最好办法就是一句代码也不写。
我觉得很有道理，bug不可避免，那么测试测出了bug之后我们要如果修改呢。
其实这里可以将bug也理解为需求，将上面的开发流程再重复一遍即可，这是一个并行的需求，需要我们从develop分支在拉取一次代码，自测完成之后，合并到develop分支，然后再合并到release分支。
当然如果测试的时间非常紧迫，我们也可以直接基于release分支来创建bugfix-1分支，本地测试完成之后直接merge到release分支来进行测试，merge到release之后，别忘记还要同步merge至develop分支。
线上BUG修改
线上bug并不可怕，可怕的是没有及时修复。亡羊补牢，为时不晚。
线上出现问题之后，第一时间根据日志和master分支代码定位问题，定位出问题之后需要基于master来拉取分支hotfix-1，以迅雷不及掩耳之势修复完问题，然后merge到master分支，发布线上。
什么你说上面的流程没有测试，怎么能直接发布线上？
如果本次无法验证， 确实需要测试来进行验证，那么可以将测试环境release分支直接切换到hotfix-1分支，测试完成之后迅速切回来，然后merge到master分支，发布线上。
当然，合并master之后，别忘记同步合并到release和develop分支。