程序员的节操

　　从代码提交记录能看出一个程序员的节操，真的。节操掉了一地
　　commit messages: ProgrammerHumor
　　在敏捷开发里我们提倡频繁提交代码，但是这并不意味着对提交的代码和提交记录的质量妥协。你身边有没有这样的程序员大哥大姐，在提交代码时是这样写的提交信息？
　　just update
　　节操仿佛掉了一地，甚至还有下面这样的。
　　just shit
　　just bug fix 规范化的代码提交记录
　　在开源社区，有这么一套规范 Conventional Commits[1] ，就是用来约定代码提交信息的格式，可以帮助大家更好的把节操抓在手里，而不是扔在地上。内容不是太长，几分钟就可以看完学会。默认格式():  empty separator line  empty separator line  当分支合并时Merge branch ＂＂
　　后面跟着默认的分支合并信息。当撤销改动时Revert ＂＂ empty separator line This reverts commit . 
　　后面跟着默认的撤销改动信息。提交类型 Type
　　提交类型可以让其他用户了解这个改动的初衷，详细列表可以在后文的参考链接找到，下面列举一些常用的类别。API relevant changes feat  Commits, that adds a new feature，新功能fix  Commits, that fixes a bug，修复问题refactor  Commits, that rewrite/restructure your code, however does not change any behaviour，重构perf  Commits are special refactor  commits, that improves performance，调优style  Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)，修改样式test  Commits, that add missing tests or correcting existing tests，测试相关docs  Commits, that affect documentation only，文档相关build  Commits, that affect build components like build tool, ci pipeline, dependencies, project version, 编译相关ops  Commits, that affect operational components like infrastructure, deployment, backup, recovery, 基础设施相关chore  Miscellaneous commits e.g. modifying .gitignore ，其他杂项
　　任何的提交记录都应该以提交类型开头，如果是很重要的改动可以选择性地加上感叹号，例如：refactor!: drop support for node 8 变更范围 Scope
　　The scope  provides additional contextual information. 变更范围是可选的，在我们实际项目中我们在这里写入了需求卡片 ID，比如 JIRA ID，当然也可以写模块名称。变更主题 Subject
　　The subject  contains a succinct description of the change. 用一句话描述改动了什么，规范里建议不操作 72 个字符，这是最能体现节操的部分。Is a  mandatory  part of the format，在规范里这是必填项。Use the imperative, present tense: ＂change＂ not ＂changed＂ nor ＂changes＂，建议语法使用现在时而不是过去时。 Don＂t capitalize the first letter，首字母不要大写。 No dot (.) at the end，末尾不要加句号。 变更详情 Body
　　The body  should include the motivation for the change and contrast this with previous behavior. 详情里主要写变更的原因和背景，而不是写改了什么，改了什么主要还是通过 diff 来了解。Is an  optional  part of the format，这是可选内容。Use the imperative, present tense: ＂change＂ not ＂changed＂ nor ＂changes＂，使用现在时而不是过去时。 This is the place to mention issue identifiers and their relations，可以放需求卡片 ID 或者相关联的其他信息 变更注脚 Footer
　　The footer  should contain any information about Breaking Changes and is also the place to reference Issues that this commit refers to. 注脚里可以放跟 Breaking Changes 之类的其他信息，或者放任何跟这次改动相关的参考信息。Is an  optional  part of the formatoptionally  reference an issue by its id.Breaking Changes  should start with the word BREAKING CHANGES:  followed by space or two newlines. The rest of the commit message is then used for this.具体例子 Examples  feat(shopping cart): add the amazing button    feat: remove ticket list endpoint   refers to JIRA-1337   BREAKING CHANGES: ticket enpoints no longer supports list all entites.    fix: add missing parameter to service call   The error occurred because of .    build(release): bump version to 1.0.0    build: update dependencies    refactor: implement calculation method as recursion    style: remove empty line 优化提交记录有什么好处
　　好处很多，首先，你的节操又捡起来了。
　　其次，良好的提交记录可以提高你的口碑和声誉，我们可以随手去知名的开源项目翻阅一下，大神们不仅对代码有极高的要求，对提交记录也一样。
　　tidy commit message
　　大家在翻开其他同行的代码时，第一眼看的并不是代码，而是提交记录，他对他的好感有时候就是那么简单自然。
　　还有，在开源社区很多项目的 Change Log 都是自动生成的，良好的提交记录就是这些自动化技术的基础。如何简化这个有点繁琐的流程
　　如果你遇到任何事情都有偷懒和简化的思维，恭喜你，你已经具有高级工程师的基本素质了。坦白讲这个规范其实也没那么烦，但是一定要简化的话还是有懒人给懒人写了工具。IDEA 可以用  Conventional Commit[2] VSCode 可以用  Conventional Commits[3]
　　我真的不是强行凑字数，它们的名字就这样。
　　还有一些插件更厉害了，可以让你的代码不按规范写 Commit Message 就没法提交，只要大家觉得这样没毛病，就可以把这个插件带到你的团队，这个插件叫，Husky[4] 。
　　关于 pre-commit-hook 和 husky 的使用，我们下次再讲，过了今天，愿你我的节操同在。