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

号外

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

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

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

​ 下图是我天天记录的📒，其余的分类因为设计到公司业务因此没有展开，在工做和生活上都与涉及。

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

​ 固然我做为一个开发来讲，更多关注的是需求的业务逻辑和优化、实现上。每一个团队都有本身的git分支规范，咱们也不例外。

Git分支规范

1. feature分支

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

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

2. bugfix分支

   不紧急的bug修复分支。命名规则是: bugfix/{创建分支的人的姓名拼音首字母}/{分支后缀名}

   ​ 和上文实现相似。

3. hotfix分支

   ​ 紧急的bug修复分支，命名规则是：hotfix/{创建分支的人的姓名拼音首字母}/{分支后缀名}

   • ​ 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上的可视化工具，进行版本对比。

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

3. 选择相应的分支后，咱们能看到两个版本上不一样的文件。此时，咱们须要根据咱们的记忆，对相应的文件进行修改。

   

4. 文件代码对比，咱们能够点击 >>,将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

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