h3. 清晰的代码提交规范，有利于我们代码方便的查找和维护。可以约定提交格式如下：
--------------------- 格式start -----------------------
<type>[scope]: <subject>
空一行
[可选的正文 body]
空一行
[可选的页脚 footer]
---------------------- 格式end-----------------------
-
type：
提交类型，必填项，详细可以分为：
feat： 新功能feature
fix：修复bug
docs： 文档注释
style：代码格式，不影响代码运行的变动
refactor：重构、优化（既不增加新功能也不修复bug）
perf：性能优化
test：增加测试
chore：构建过程或者辅助工具的变动
revert：回退
build：打包
ci：与ci 持续集成有关的改动
temp：临时代码，不计入 CHANGELOG，比如必须部署到某种环境才能测试的变更。如测试真机上 transparent title 启动参数是否设置成功
- scope：
scope也是必填项，用于描述改动范围，格式一般为 项目名/模块名 例如：
node-pc/common
如果一次commit修改多个模块，建议拆分为多次commit，以便更好的追踪和维护。
- subject：
填写简单的提交说明，言简意赅，不超过50字，可以清晰明了的指出修改的意图。
- body：
选填，用于填写更详细的描述。主要描述改动之前的情况和修改动机，对于小的修改可以没有，但是重大需求、更新等必须添加body来作说明。
- footer：
选填，用填写关联的issus，或者BREAK CHANGE.
必须是大写，表示引入了破坏性 API 变更，通常是一个大版本的改动，BREAKING CHANGE: 之后必须提供描述，下面一个包含破坏性变更的提交示例:
feat: allow provided config object to extend other configs
BREAKING CHANGE:extendskey in config file is now used for extending other config files
当然，一方面规范需要大家都自觉遵守，但是使用现有的工具来约束规范可以达到事半功倍的效果。所以针对不同的开发环境可以选择合适自己的代码提交规范格式化工具，利用git hooks来约束提交规范。 __
网友评论