约定式提交规范是一种基于提交信息的轻量级约定。 它提供了一组简单规则来创建清晰的提交历史； 这更有利于编写自动化工具
提交说明的结构如下所示
<type>[scope]: <description>
[body]
[footers]说明:
-
type
必填, 意为提交类型, 分别有以下可选值
build 构造工具的或者外部依赖的改动 chore 其他一些不影响源码或测试文件的代码变动 ci 修改CI(持续集成)配置文件或相关的脚本 docs 只改动了文档相关的内容 feat 增加新功能 fix 修复bug perf 与性能优化相关的改动 refactor 代码重构, 但不影响原有业务 revert 执行git revert撤销用 style 不影响代码含义的改动，例如去掉空格、改变缩进、增删分号 test 添加测试或者修改现有测试 -
scope
可选, 意为改动影响的范围/模块
-
description
必填, 改动的简短描述，不超过50个字符
-
body
可选, 对本次提交的详细描述, 可以包含多行
-
footers
可选, 脚注说明, 可以同时存在多个脚注, 脚注一般用于以下两种情况
-
不兼容变动
使用 "BREAKING CHANGE:" 作为开头, 用于描述本次改动导致的与之前版本不兼容的情况, 后面需要补充该不兼容变动的描述以及变动理由和迁移办法
-
关闭问题
使用 "Closes" 后跟关闭的问题编号, 多个问题可以分多行也可以在一行用逗号隔开
-
fix(api): 修复数据查询接口偶发的错误问题
当redis缓存中没有数据时, 通过数据库查询到的数据在返回前会被放入redis缓存起来, 以便下次使用
当数据库数据被删除后, 同步删除redis中的缓存不及时, 导致再次查询时返回了错误
Close #123
-
每个提交都必须使用类型字段前缀, 它由一个名词构成, 诸如 feat 或 fix, 其后接可选的范围字段, 可选的(!), 以及必要的(:)和空格
-
当一个提交为应用或类库实现了新功能时, 必须使用 feat 类型
-
当一个提交为应用修复了 bug 时, 必须使用 fix 类型
-
范围字段可以跟随在类型字段后面, 范围必须是一个描述某部分代码的名词, 并用圆括号包围
-
描述字段必须直接跟在 <类型>(范围) 前缀的冒号和空格之后, 描述指的是对代码变更的简短总结
-
在简短描述之后, 可以编写较长的提交正文, 为代码变更提供额外的上下文信息, 正文必须起始于描述字段结束的一个空行后
-
提交的正文内容自由编写, 并可以使用空行分隔不同段落
-
在正文结束的一个空行之后, 可以编写一行或多行脚注, 每行脚注都必须包含一个令牌(token), 后面紧跟 : 或 # 作为分隔符, 后面再紧跟令牌的值
-
脚注的令牌必须使用 - 作为连字符, 比如 Acked-by (这样有助于 区分脚注和多行正文), 有一种例外情况就是 BREAKING CHANGE，它可以被认为是一个令牌
-
脚注的值可以包含空格和换行, 值的解析过程必须直到下一个脚注的令牌/分隔符出现为止
-
破坏性变更必须在提交信息中标记出来, 要么在 <类型>(范围) 前缀中标记, 要么作为脚注的一项
-
包含在脚注中时, 破坏性变更必须包含大写的文本 BREAKING CHANGE, 后面紧跟着:空格, 然后是描述
-
包含在 <类型>(范围) 前缀时, 破坏性变更必须通过把!直接放在:前面标记出来, 如果使用了!, 那么脚注中可以不写 BREAKING CHANGE:, 同时提交信息的描述中应该用来描述破坏性变更
-
在提交说明中, 可以使用 feat 和 fix 之外的类型
-
工具的实现必须不区分大小写地解析构成约定式提交的信息单元, 只有 BREAKING CHANGE 必须是大写的
-
BREAKING-CHANGE 作为脚注的令牌时必须是 BREAKING CHANGE 的同义词
- 可以自动化生成 CHANGELOG
- 基于提交的类型，自动决定语义化的版本变更
- 向同事, 公众与其他利益关系者传达变化的性质
- 触发构建和部署流程, 例如: 持续集成环境下, 当git hook捕捉到新提交时, 判断提交类型如果是fix或feat类型的提交, 则执行部署流程, 否则不执行
- 让人们探索一个更加结构化的提交历史，以便降低对你的项目做出贡献的难度
?> 待补充