继前天看分享的前后端分离后，又重新研究了GIT分支与各个环境的应用。
从开始使用git就一直有在网上查各种资料，查他的运行规范。但不知道是自己理解不够还是怎么的，一直用得不是很好。
根据自己的摸索，整理了一个适合自己团队工作的运行规范。欢迎大家评论区留言拍砖，有用的话点个赞。^_^
在工作执行中老遇到这2个问题：
1、测试环境是正确的，但到准生产或生产的时候会出现一些没测试覆盖到的问题，尤其是多个功能集成上线的时候，这些问题会凸显；
2、一个项目同时多个人提测，测到一半发现其中一个人的功能问题太多，不能一起上线。这时候，测试分支就不能往Release推了。那我们把另外可以上线的功能重新创建条分支就好了。但这样会有个问题，我们测试环境只有一个，测试要上线的功能时其他功能的测试工作就得停止了。
开始我想可以直接把这要上线的功能分支合并成一个新的Release分支，但这样集成后的代码在没测试过就进预发环境了。这也就是问题1多发的原因。这是极其不稳定，不严谨的。
为了解决上面的问题我把工作规范改成了这个结构：
服务器环境： 生产、准生产、集成测试、综合测试、开发
Git主干线： Master、Hotfix、Release、SIT、SVT、Develop
我把测试这一层分成了SIT和SVT两层。先上流程图，看看整个工作流程是怎么样的。
服务器环境说明：
开发：自己本地服务，开发新功能，修改Bug；
综合测试：开发人员开发完成后代码合并到SVT主线发布到测试环境，可以进行自测。测试人员大部分工作也会在这个环境进行。这个环境的包括了要上线，测试中，正在修改的所有功能代码；
集成测试：每次确认可以上线的功能后，开发人员合并各功能代到GIT的SIT主线并发布到这个环境。测试人员对集成后的代码进行确认测试；
把测试环境分成2个环境的主要原因：
1、保证预发布版确认上线的功能是经过测试的。
2、并且集成测试和综合测试工作可以并行
准生产：集成测试完成后，把集成好的代码直接推至Release主线，并发布到准生产环境，待产品经理验收；这个环境的数据应该是根线上数据同步的；
生产：验收成功，把Release分支合并到master并发布生产；
Git主干线说明
Master 生产稳定主线;
线上稳定分支版代码，这条主干是长期稳定存在的；
这条线只可以合并Release 和 Hotfix 这俩条主线的代码；
每次生产主线更新，应该同步至当下所有的正在进行的开发分支；
Hotfix 紧急修复主线；
如果线上发现需要紧急修复的BUG。就直接以Master为基础，拉出一条Hotfix分支。修复完成立即合并回Master分支，并同步到当前的开发分支；
这条主线是每个小bug就会有一条分支。修复完成的小bug稳定后删除当前分支即可。
Release 预发布主线；
上线前把集成测试完成后的分支带着版本号推送到预发主线，部署代码到相应环境，待产品验收。
验收成功则合并至Master分支并发布到线上；
如果在验收时有Bug需要修复，则直接在当前分支修复Bug；
这条主线是由多条带版本号的分支组成，且不应该删除历史版本号的分支；
SIT 集成测试主线;
这条主线主要用于某个或多个功能测试通过后，把确认上线功能之间，以及线上做好集成后的测试；
每次集成都使用Master作为基础创建一条带版本号的新分支，把要上线的功能合并。然后部署到集成测试环境中去。
这里测试发现Bug，修复需要在相应的dev分支修复，然后再合并到此分支来。
测试做完确认测试后，推送到Release即可。
这里也是由多条带版本号分支组成的，不过这里的分支可以在上完线稳定后进行删除。
SVT 综合测试主线；
这条主线只会有一条分支，测试的功能会相对较多，所有的功能，是不是一起上线都会往这条分支合并。保证测试人员可以同时测试多个功能模块；
这环境发现的Bug也是需要在相应的Dev分支修复，再合并过来；
注意，这条分支太杂了，所以它只进不出！！不要把它合并到任何分支去；
Develop 开发主线;
这条主线就是我们的开发分支了，同时多人开发，就按人员开发的功能进行分支区分；
至于线上有Bug非紧急的也是拉取Develop分支出来改。
分支命名方式建议使用开发人员进行命名，在刚开始多人开发的时候建议使用人员区分来命名。后期维护期人少，迭代升级的时候使用功能区分；
