git在生产中的版本控制流程
git介绍:Git是一个开源的分布式版本控制系统,可以有效、高速地处理从很小到非常大的项目版本管理。
那么git是如何在生产中进行版本控制的?
首先在整个git管理的项目中会分为四个分支
- dev(开发分支)
- test(测试分支)
- pre(预生产分支)
- master(生产分支)
在开发过程中出现若干个feature_XXX分支并行开发,若干个hotfix_XXX分支进行热修复
- feature_XXX(个人开发分支)
- hotfix_XXX(热修复分支)

程序员在开发一个新功能的时候,需要从master分支中拉取并创建一个新的分支,命名方式为feature_XXX,并在这个分支中开发新的功能。
当该功能开发完成后,会从这个feature_XXX分支merge到dev分支中进行自测。

自测通过后再将自己的feature_XXX分支merge到test分支中交给测试同学进行提测。

当测试通过后,将自己的feature_XXX分支merge到master分支中,再从master分支merge到pre分支,并将这个分支的代码部署发布实测,如果实测没有问题,再将master分支的代码部署发布出去。

当发现bug的时候,需要从master分支拉取并创建一个新的分支,命名方式为hotfix_XXX。
hotfix_XXX分支中的bug修复完毕后在pre中部署上线,如果实测没有问题,再将pre分支merge到master当中发布,完成bug的修复。

在开发与测试环节中为什么我的自测没有问题了,还要从feature_XXX分支merge到test分支呢?
原因是如果组内并行开发其他功能的程序员并没有完成自测,此时提测可能会出现过多的问题,同样的,提测之后也不能从test分支merge到pre分支,因为会有其他程序员提测,这时从test分支进行merge会出现许多问题。
另外需要注意的是所有的特性分支,不允许push,能push的分支只有feature分支。merge是需要审批的,方便代码reivew。
Git是一个分布式版本控制系统,项目通常有dev、test、pre和master四个分支。开发者在feature_XXX分支开发新功能,完成后合并到dev自测,通过后依次合并到test、master和pre分支。热修复bug时,从master创建hotfix_XXX分支,修复后先在pre上线,没问题再合并到master发布。所有特性分支不允许直接push,需经过审批和代码审查。
1429

被折叠的 条评论
为什么被折叠?



