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

╰半夏微凉° 2023-06-10 06:30 9阅读 0赞

## 号外 ##

最近因为换工作的原因，我的博客和Github没有像之前那样频繁的更新了。一方面原因是投递简历和准备 [面试][Link 1]，由于之前的基础没有很扎实，需要把平时的知识点都整理一遍。这个时间段持续了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.  选择相应的分支后，我们能看到两个版本上不同的文件。此时，我们需要根据我们的记忆，对相应的文件进行修改。![代码一览\_www.wityx.com][www.wityx.com]
2.  文件代码对比，我们可以点击 **>>**,将deploy-test上的代码挪到自己的分支上去。

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

## 总结 ##

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

## 资源推荐 ##

### 工具推荐 ###

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

实际效果如下图所示

### 快速安装 ###

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

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

### 简单使用 ###

这里推荐阮一峰的博文：[http://www.ruanyifeng.com/blog/2016/01/commit\_message\_change\_log.html][http_www.ruanyifeng.com_blog_2016_01_commit_message_change_log.html]

### 走进Git ###

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

[Link 1]: http://www.wityx.com
[www.wityx.com]: /images/20230531/151a2d25b7604983ba229b841303d367.png
[commitizen]: https://github.com/commitizen/cz-cli
[https_gitmoji.carloscuesta.me]: https://gitmoji.carloscuesta.me/
[https_nodejs.org_en]: https://nodejs.org/en/
[http_www.ruanyifeng.com_blog_2016_01_commit_message_change_log.html]: http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html
[Git]: https://marklodato.github.io/visual-git-guide/index-zh-cn.html
[Git 1]: http://www.iocoder.cn/Fight/Git-command-quick-reference-manual/?vip
[Git 2]: http://www.iocoder.cn/Fight/Git-commits-records-and-branching-models/?vip
[Git 3]: http://www.iocoder.cn/Fight/I-have-to-share-Git-resource-summary-with-you/?vip