git commit 规范
git commit 规范
概述
参考文章：
在我的个人的编码体验中，写完代码后add .、commit -m xxx、push这几个步骤往往是最大快人心的，每每潇洒地输完这几个命令后胸中就充满了自豪感！
可冷静下来回过头再去思考自己写下代码、以及使用 git 的目的或者说初衷时，不禁悲从心来，这么一款强大的工具在我手上变成了一种自我愉悦的玩具（至今没有使用到“版本控制”的相关功能，只是一个远程备份平台），简直暴殄天物。
那怎么办？当然只有一点点地改进呗。具体的改进点有许多，后续会陆续编成文字发布在博客，今天只记录一下 commit 的规范。
commit 最重要的无非就是附带的提交信息，提交信息要准确的表明与修改相关的可能产生实际影响的因子（我是这样理解的），翻阅了几篇博文后，终于找到了一些业界普遍认可的 commit 相关的规范。
不就是 commit 信息吗？我说人话不就行了，还有人看不懂人话？话大家都会说，高效且简洁的说话却不是人人都会，或者说每个人说话的方式和侧重点都不同，比如有人说话就诗情画意的：
当然，自己说的话肯定自己都能懂，问题是在大多数情况下，你说话是为了让别人理解你自己。满口之乎者也，往往会被暴打！
commit 规范
对于一般的 commit，我们往往不需要过为详尽的阐述，言简意赅即可，所以，请使用以下的格式：
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
其中最关键的是第一行的部分（除此以外的部分除非有特殊的要求，否则往往不用填写）：
<type>(<scope>): <subject>
type（必须）
用于说明git commit的类别，只允许使用下面的标识：
- feat：添加新特性
- fix/to
- fix：产生 diff 并自动修复此问题。适合于一次提交直接修复问题
- to：只产生 diff不 自动修复此问题。适合于多次提交。最终修复问题提交时使用 fix
- docs：仅仅修改了文档
- style：仅仅修改了空格、格式缩进、逗号等等，不改变代码逻辑
- refactor：代码重构，没有加新功能或者修复 bug
- perf：优化相关，比如提升性能、体验
- test：增加测试用例
- chore：改变构建流程、或者增加依赖库、工具等
- test：增加测试
- revert：回滚到上一个版本
- merge：代码合并
- sync：同步主线或分支的Bug
如果不想使用这么生硬的文字，还可以通过更加有趣的 emoji 来表示咱么的提交类型，这个网站罗列了我们可能用到的提交时使用的 emoji 并且提供了搜索功能，使用体验非常 nice，但是要注意，团队开发一定要在其他成员知道相关 emoji 含义的前提下使用。使用的方法就是
:emoji: (scope) subject
scope（可选）
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。如果修改影响了不止一个 scope，你可以使用 * 代替。
subject（必须）
subject 是 commit 目的的简短描述
- 不超过50个字符；
- 以动词开头，使用第一人称现在时，比如
change，而不是changed或changes； - 第一个字母小写；
- 结尾不加句号或其他标点符号
IDEA 中优雅地 commit
这一套规范相信在大多 IDE 软件中都已经集成有实现或者是能够使用插件拓展实现，在 IDEA 中就有这么两款插件：
第一个是严格规则的实现，很标准，还可以关闭指定的 issue。
第二款则是对 emoji 的集成。
这两个图标对应安装的两个插件：
总之使用起来非常优雅，但是对于新手还是建议先手打适应一段时间！
总结
最后，我们的一个 commit message 可能长成这样：
fix(DAO):用户查询缺少username属性
feat(Controller):用户查询接口开发
要知道 git 里面和版本控制相关的学问可太多了，不要着急，别想一口吃成胖子，慢慢来，日进一卒，先把习惯一点点地积累起来！
极客时间上有一门相关的非常详细的课程：https://time.geekbang.org/course/intro/100021601，请大力支持知识付费！
