要提高团队代码质量,就要这么用Git进行版本控制!

发表于:2019-1-21 11:52

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:煮酒科技    来源:思否

  大家都比较清楚,互联网产品要能够快速响应市场变化,要面对频繁的需求变更,要用廉价的成本快速试错,这样才能不断的完善和优化产品。
  Git是一个开源的分布式版本控制系统,可以有效、高速的处理从很小到非常大的项目版本管理。非常适合做互联网产品的代码版本管理。
  一个团队如何如何使用git进行版本管理,如何使用git进行多人的代码写作?如何解决产品开发过程中的提出来的版本控制的问题?就是我要表达的意思。
  团队如何进行版本管理呢?
  第一,GitServer的选型和安装
  我选用了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上一次的版本代码。
  第六,线上从来不缺bug,如何处理线上紧急Bug呢?
  1)研发人员从继承master分支创建一个hotfix分支。
  2)研发人员检出hotfix分支,自测通过后提交并申请分支合并到release分支,由管理审核通过后完成合并,并部署到预生产环境。
  3)由测试人员对预生产环境进行测试,测试通过后,由研发人员发起从release分支合并到master分支的申请,由管理员审核通过后完成合并,并在master分支上打版本标签,并部署到生产环境。
  4)测试人员验证生产环境通过后,上线完成,如果生产环境验证不通过,马上回滚到master上一次的版本代码。
  以上就是我使用GitLab进行版本管理的实际使用过程,大家有什么想法可以一起讨论。

      上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。


《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号