记因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. 选择相应的分支后，我们能看到两个版本上不同的文件。此时，我们需要根据我们的记忆，对相应的文件进行修改。

代码一览

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

代码对比

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

发布成功

总结

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

资源推荐

工具推荐

1. 我们在每次提交代码时，都需要编写Commit Message，否则是不允许提交的。 git commit -m first commit with userInfo service，编写Commit Message需要遵循一定的范式，内容应该清晰明了，指明本次提交的目的，便于日后追踪问题。 commitizen 就是这么样一款工具,他用来规范化我们的commit消息。
2. ​ 因为git的commit提交是支持emoji表情的，所以在非正式场合或者想趣味性的表达自己的提交信息，可以在调教信息中添加emoji代码，具体网址参考: https://gitmoji.carloscuesta.me/

实际效果如下图所示

快速安装

1. 安装nodejs（https://nodejs.org/en/）
2. 安装commitizen，在用户目录下配置

cd ~ npm install -g commitizen commitizen init cz-conventional-changelog --save --save-exact

走进Git

• marklodato 《图解 Git》
• 超哥 《Git 常用命令速查手册》
• 猫尾 《Git 提交记录和分支模型》
• 自由 《我必须分享给大家的 Git 资源汇总》