雪飞海 2019-06-29
大家都比较清楚,互联网产品要能够快速响应市场变化,要面对频繁的需求变更,要用廉价的成本快速试错,这样才能不断的完善和优化产品。
Git是一个开源的分布式版本控制系统,可以有效、高速的处理从很小到非常大的项目版本管理。非常适合做互联网产品的代码版本管理。
一个团队如何如何使用git进行版本管理,如何使用git进行多人的代码写作?如何解决产品开发过程中的提出来的版本控制的问题?就是我要表达的意思。
团队如何进行版本管理呢?
我选用了GitLab作为GitServer。GitLab是一个开源的版本管理系统,实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目。它拥有与Github类似的功能,能够浏览源代码,管理缺陷和注释等,还有一个功能,它能够实现分支的在线合并申请,分支可以进行保护等权限的控制。
约定版本号规范,每个模块的版本号约定为三位<main>.<feature>.<hotfix>,根据大的基线设定<main>主要版本号,根据当前版本设定<feature>次版本号,<hotfix>默认为0,当有bug修改后才更新这个版本号。每次产品人员定义好产品功能后,每次变更<feature>版本号即可。
每创建一个项目,分别创建dev、test、release、master四个固定分支。
dev分支用来研发人员进行自测和模块间联调使用的,用来部署到研发环境的,开发人员对该分支有pull和push权限。
test分支是测试人员进行测试的代码分支,是部署到测试环境的代码分支,研发人员联调完自测完成后,提交feature分支合并申请到test分支,由管理员负责代码review并进行代码合并,该分支是受保护分支,开发人员对该分支有pull权限。
release分支是在test分支测试完成后,由研发人员提交test分支合并申请到release分支,release代码分支是用来部署到预生产环境的,由管理员进行代码合并。
master分支是最终上线的代码分支,测试人员在预生产环境测试通过后,由研发人员提交release代码分支合并申请到master分支,master分支是要部署到生产环境的,master上线完成后打对应版本的tag标签。
feature分支,每次定义产品一个完整的基线版本就生成一个feature_{版本号}分支,上线完成后删除该分支,所有的人创建一个属于自己的分支,每个人自测完成后,发起自己分支合并到feature分支,然后将feature分支合并到dev分支。
hotfix分支,每次bug修复创建一个hotfix_{版本号}分支,生产环境出现bug后,需要马上修改时,确定好版本号,从继承master分支创建hotfix分支。
1)管理员创建固定的分支dev、test、release和master版本,根据产品人员确定的功能确定当前版本的版本号,并继承master分支创建feature分支。
2)每个研发人员拉取feature分支,并创建个人本地分支。
3)研发人员进行编码,自测完成后合并本地分支合并到feature分支,并将feature分支合并到dev分支部署到研发环境进行模块间联调。
4)研发人员联调通过以后,向管理员发起feature分支合并到test分支的申请,由管理员review代码后完成合并,并部署到测试环境。
5)测试人员在测试环境进行测试,发现bug并登记,由研发人员进行修改,重新从第3步开始重复执行。
6)测试人员测试通过以后,由研发人员发起从test分支向release分支合并申请,由管理员完成合并,并部署到预生产环境。
7)测试人员测试预生产环境测试通过后,由研发人员发起从release分支向master分支的合并申请,有管理员完成合并,并在master分支上打版本标签,并部署到生产环境。
8)测试人员验证生产环境通过后,上线完成,如果生产环境验证不通过,马上回滚到master上一次的版本代码。
1)研发人员从继承master分支创建一个hotfix分支。
2)研发人员检出hotfix分支,自测通过后提交并申请分支合并到release分支,由管理审核通过后完成合并,并部署到预生产环境。
3)由测试人员对预生产环境进行测试,测试通过后,由研发人员发起从release分支合并到master分支的申请,由管理员审核通过后完成合并,并在master分支上打版本标签,并部署到生产环境。
4)测试人员验证生产环境通过后,上线完成,如果生产环境验证不通过,马上回滚到master上一次的版本代码。
以上就是我使用GitLab进行版本管理的实际使用过程,大家有什么想法可以关注我的公众号(xtech100)一起讨论。
我在百家号上文章地址