阅读 27

记因git规范导致的提测和发布延迟

号外

背景图

近因为换工作的原因,我的博客和Github没有像之前那样频繁的更新了。一方面原因是投递简历和准备面试,由于之前的基础没有很扎实,需要把平时的知识点都整理一遍。这个时间段持续了20多天的样子,因为今年的互联网市场遇冷,简历反馈率都不是很好。

​ 我一共投递了菜鸟网络,天猫超市,有赞,大搜车和涂鸦智能等公司,都收到了面试邀请。菜鸟网络和涂鸦智能投递的职位方向都是我比较感兴趣的IOT,有赞投递的是风控和大搜车的新零售职位,后两个都是我之前的没有接触过的领域。最后由于各方面的考虑(没面试成功和对工作以及生活的平衡),我选择了之前没有接触过的大搜车新零售领域的职位。

​ 但是今天我想说的并不是面试经历,而是我标题所描述的工作中发生的有趣的事。因为新入职一个公司,需要对工作流程和项目代码进行熟悉,同时还需要对新零售这个领域和行业需要进行了解和认识。所以拿到产品分配给我的需求,我大部分的时间都是花在了需求整理和询问同事上了,真正花在写业务需求上的时间是很少的。

​ 下图是我每天记录的📒,其他的分类由于设计到公司业务所以没有展开,在工作和生活上都与涉及。

备忘录

​ 一般我们的产品需求周期是这样的: 产品整理需求池 -> 交互评审 -> 技术评审 -> 联调 -> 提测 -> 预发 -> 发布。

​ 当然我作为一个开发来说,更多关注的是需求的业务逻辑和优化、实现上。每个团队都有自己的git分支规范,我们也不例外。

Git分支规范

  1. feature分支

    开发新功能时,应用从develop分支简历feature分支。命名规则时: feature/{ 建立分支时的日期,yyyyMMdd格式 }/{建立分支的人的姓名拼音首字母}/${分支后缀名}

    • 建立分支的人的姓名拼音首字母: 例如,开发者是"穆书伟",这里就是msw,要求全小写。
    • 建立分支时的日期: 例如,20191025。
    • 分支后缀名:如果我需要开发博客文章这个需求,可能这里我写的名称是 blog_article,要求全小写,用下划线格式。
    • feature分支开发完毕,和前端联调时,将此分支合并到测试分支上(deploy-test)。当联调完毕,我们需要将分支合并到预发环境上(deploy-prepub),此时我和前端需要写提测单,将需求实现内容给测试工程师进行测试(下面可能有和此雷同的内容,下面的博文我会以【上文实现】来代替)。
  2. bugfix分支

    不紧急的bug修复分支。命名规则是: bugfix/{建立分支时的日期,yyyyMMdd格式}/{建立分支的人的姓名拼音首字母}/{分支后缀名}

    ​ 和上文实现类似。

  3. hotfix分支

    ​ 紧急的bug修复分支,命名规则是:hotfix/{建立分支时的日期,yyyyMMdd格式}/{建立分支的人的姓名拼音首字母}/{分支后缀名}

    • ​ hotfix和feature/bugfix不同是,hotfix是master出来的,而上面的分支是从develop分支建立的,因为要紧急发布。

    • 和上文实现类似。

  4. release分支

    release可以比较有效的避免发布搭车的情况,这个分支目前比较少用到,因为运维是发布的master分支,使用方式为用git flow release去生产。

错误案例

​ 本来我作为一个有三年开发经验的工程师,我本不应该犯以下的错误。但Jira(bug管理工具)不断弹出被测试提出来的bug和当时远没有现在写这篇博客时, 对公司的规范十分熟悉的情况下,我做出了十分愚蠢的举动。

​ 为了尽快的看到自己写的代码是否修复bug,我不仅仅在自己的分支上修改了需求实现,而且也在deploy-test上做了改动但是没有同步到自己的分支上。当我解决完Jira上所有bug时,满心欢喜的想要把分支合并到develop上时。我一看代码,回想到了整个过程,此时,我是绝望而又懵逼的。此时电脑的时间已经走到了16:30,我抓耳挠腮,不知道怎么办了。

此时,大家可能会注意到deploy-test上有完整的我修复的程序,因为deploy-test是联调和测试过的代码。此时很多小伙伴在我当时的情况下,会把deploy-test合并到develop上。但是deploy-test分支太过脏乱,有很多其他开发人员写的测试代码和打印日志代码。永远不要把deploy-test分支合并到自己的分支,也不要合并到develop和master分支上

以前我认为钉钉是一个提高工作效率的IM软件,但是此时的它如悬在我头顶上的倒计时的💣。未读->已读,短时间没有读,就会DING。未读->5-10分钟没有解决,钉钉电话☎️就会打过来。

此时我还是沉下心来,把之前在deploy-test上修改的部分而未同步到自己的分支上的代码移过来。以下是我的IDEA操作步骤,当然大家也可以用其他可视化工具或者命令行。

  1. 切换到自己的分支上,利用IDEA上的可视化工具,进行版本对比。

版本对比

  1. 选择远程的deploy-test分支,进行版本代码对比。

线上分支

  1. 选择相应的分支后,我们能看到两个版本上不同的文件。此时,我们需要根据我们的记忆,对相应的文件进行修改。

    代码一览

  2. 文件代码对比,我们可以点击 >>,将deploy-test上的代码挪到自己的分支上去。

代码对比

​ 做了上面紧急的处理后,我又在本地运行了程序,做了简单的自测并在最后的关头给测试写了提测单。经测试无误后,发不到了线上,此时,我的心在落到了肚子里。

发布成功

总结

​ 开发是个技术性工作,而团队开发是一个纪律性、团队合作性和有一定哲学性的学问。虽然上面👆的条条框框让我的开发效率变得很不好,当然这个效率是相对个人而言。因为每开发一个新需求就需要建立分支,合并代码到各种环境,对于一个不细心和急躁的工程师,光这个工作都令人烦恼了。但是对于一个团队来说,以上的条条框框对于整个团队是高效而又不会出错的。在这里,笔者有个小问题,你们团队的git工作流程又是怎么样的呢?麻烦告知一下。

资源推荐

工具推荐

  1. 我们在每次提交代码时,都需要编写Commit Message,否则是不允许提交的。 git commit -m first commit with userInfo service,编写Commit Message需要遵循一定的范式,内容应该清晰明了,指明本次提交的目的,便于日后追踪问题。 commitizen 就是这么样一款工具,他用来规范化我们的commit消息。

  2. ​ 因为git的commit提交是支持emoji表情的,所以在非正式场合或者想趣味性的表达自己的提交信息,可以在调教信息中添加emoji代码,具体网址参考: gitmoji.carloscuesta.me/

实际效果如下图所示

快速安装

  1. 安装nodejs(nodejs.org/en/)
  2. 安装commitizen,在用户目录下配置

cd ~

npm install -g commitizen

commitizen init cz-conventional-changelog --save --save-exact

简单使用

这里推荐阮一峰的博文:www.ruanyifeng.com/blog/2016/0…

走进Git

关注下面的标签,发现更多相似文章
评论