GIT管理以及运行规范

继前天看分享的前后端分离后，又重新研究了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分支出来改。

　　　　分支命名方式建议使用开发人员进行命名，在刚开始多人开发的时候建议使用人员区分来命名。后期维护期人少，迭代升级的时候使用功能区分；

 

 

 

转载于:https://www.cnblogs.com/hrw3c/p/11395596.html