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


    摘自:https://www.cnblogs.com/cloudman-open/p/12169029.html

    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
  • 相关阅读:
    NSPredicate的用法、数组去重、比较...
    CocoaPods安装和使用教程
    UITableView学习笔记
    Linux dpkg 命令
    Linux rpm 软件包管理命令
    Linux chmod 文件权限命令
    Linux vi 命令
    分库分表背后那些事儿
    Spring Cloud Feign原理及性能
    linux "No space left on device" 磁盘空间解决办法
  • 原文地址:https://www.cnblogs.com/xichji/p/12178942.html
Copyright © 2020-2023  润新知