码迷,mamicode.com
首页 > 其他好文 > 详细

我与Git的那些破事--代码管理

时间:2020-01-08 22:47:50      阅读:91      评论:0      收藏:0      [点我收藏+]

标签:项目   接受   结束   完成后   ase   idt   新版本   ast   其他   

1. Git是什么?

作为一名程序猿,我相信大家都或多或少接触过git--分布式版本控制软件。

有人说,它是目前世界上最先进的分布式版本控制系统,我想说,是否最先进不知道,但确实好用,实用。

作为一款风靡全球的软件,不得不提提它的历史:

  --由Linus Torvalds创作,并与2005首次发布,最初仅是为更好的管理Linux核心开发而设计,不曾想太优秀,如今已被广为使用。

2. 我们可用Git来干什么?

作为一款分布式版本控制软件,听上去高端大气上档次,但说白了,就是一款项目代码管理工具。

3. 如何正确使用Git?

既然Git如此好用,理所当然,目前全球各大公司大多采用该软件作为项目代码的管理工具。

犹记得当初刚从学校进入企业,发现原来公司的代码是这样管理的,看上去猴塞雷的样子。当然,伴随着操作小心翼翼,生怕一顿操作猛如虎,犯错回家卖红薯。。

作为一个接触多年的老手,则肆无忌惮,斧削刀砍,好不快活。讲真,那会羡慕的不要不要~~

其实,只要懂得正确操作流程,你也可以大刀阔斧,那么下面的知识,你值得拥有!!

4. 项目管理

好了,闲话就此打住,还是得来点干货。

我相信大家一定听过一句话:作为一款稳定的产品,我们一定要保证项目运行的四个九。咋听之下,一脸狐疑。其实,意为保证项目运行99.99%(至于那遁去的1,你懂的),即高可用的又一说法。

为保证项目高可用,产品上线必须严格遵守一定的流程。

这里提几个概念,可能与你所在公司说法不太一样,但我相信都是换汤不换药,领略精髓即可,大可不必咬文嚼字。

Git 分支:

  • master--该分支一般作为备份使用,通常为最稳定代码。
  • dev--该分支作为开发分支,持续开发,持续集成。
  • feature--该分支作为需求开发分支,生命周期由需求创建到完成。
  • release--该分支作为版本发布分支。
  • hotfix--该分支作为bug修复分支,发布版本存在重要缺陷时,拉出该分支,并由该分支发布hotfix版本。

部署环境:

  • DEV/Local环境--本地环境。一般而言,程序猿接到一个新的需求时,会在本地开发,完成后自己测试,这里称为本地环境(当然财大气粗的公司可能会专门准备一套DEV环境用于测试)。
  • QA环境--与产线环境配置一致(单实例)。需求本地测试通过后,部署到QA环境中,由QA进行测试。由于QA环境部署频繁,如果多实例部署会造成资源和时间上的浪费。
  • BTS环境--与产线环境完全一致(分布式)。在版本发布前,部署到BTS环境,该环境和产线环境完全一致。一般会在版本发布前3天部署到该环境,做UAT(用户接受测试)。
  • PROD环境--分布式系统。产线环境。

4.1 新需求:

开发流程:

技术图片

  • 当团队接到新的需求时,一般会安排某个或某几个程序猿来开发该功能。在了解完需求和设计后,开发会拉出对应的feature分支,所有该需求的代码都将在该分支上进行开发。
  • 当开发完成,为验证功能可行性,程序猿需要在本地进行对应测试,通过后将代码合入到dev分支。
  • 利用Jenkins从dev分支中进行打包,然后部署到QA环境中,由团队中专职QA进行功能测试。测试不通过,上述步骤重复。测试通过,该需求结束。

这里,有些小伙伴则会问,为什么本地测试通过了,而在QA环境中却不通过呢?

     通常,一个团队都会同时接多个需求,大家的代码都会并行往dev中合入,这时就有可能影响到其他的需求,或者被其他需求影响,导致bug。

Git详细流程:

技术图片

4.2 发布新版本

开发流程:

技术图片

  • 当发布新版本时,以时间或需求结束点为节点,打对应tag(方便以后回溯)。从该tag拉出release分支,Jenkins从release分支打包。
  • 将包部署到QA环境,由专职QA进行测试。
    • 如果测试不通过,从release分支中拉出hotfix分支,在hotfix分支上进行bug修复,本地测试完毕,Jenkins从hotfix分支打包,部署到QA环境测试。
    • 测试通过,下一步。
  • 将包部署到BTS环境,由专职QA进行测试。测试不通过,判断当前分支,若为release分支,则从该分支拉出hotfix分支,在hotfix修复bug后;若为hotfix分支,则直接修改bug,本地测试完毕,Jenkins打包hotfix分支,部署到QA测试。
  • 将包部署到PROD环境,由专职QA进行测试,测试不通过, 判断当前分支,若为release分支,则从该分支拉出hotfix分支,在hotfix修复bug后;若为hotfix分支,则直接修改bug,本地测试完毕,Jenkins打包hotfix分支,部署到QA测试。

Git详细流程:

技术图片

上述的内容,仅为个人多年开发经验总结,或许与标准流程有一定的出入。

如有错误之处,忘各位大佬不吝斧正。


 

作者:吴家二少

博客地址:https://www.cnblogs.com/cloudman-open/

本文欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接


我与Git的那些破事--代码管理

标签:项目   接受   结束   完成后   ase   idt   新版本   ast   其他   

原文地址:https://www.cnblogs.com/cloudman-open/p/12169029.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!