我报名参加金石计划1期挑战——瓜分10万奖池，这是我的第1篇文章，点击查看活动详情
作为程序员，代码是我们平时打交道最多的，好的代码也是我们向外展示的一部分。
通常我们都是用Git来作为管理代码的工具，一份好的提交记录有助于我们后面分析代码以及减少同时的吐槽。
之前我司整理了一份规范，目前实践下来，效果良好，我们的git提交记录小而美，而且比较线性，分支不杂乱。
代码提交规范
本文档中的关键词 “必须”、“禁止”、“需要”、“应当”、“不应当”、“应该”、“不应该”、“推荐”、“可以” 和 “可选” 应按照 RFC 2119 的描述解释。
Commit Message规范
Git 是目前世界上最先进的分布式版本控制系统，每次提交代码时，都需要写 Commit Message (提交说明)，否则就不允许提交，在工作中一份清晰简洁规范的 Commit Message 能让后续代码审查、信息查找、版本回退都更加高效可靠。平时提交的变动信息应该遵循 Angular 规范的，约定式提交优点：
- 自动化生成 CHANGELOG。
- 基于提交的类型，自动决定语义化的版本变更。
- 向同事、公众与其他利益关系人传达变化的性质。
- 触发构建和部署流程。
- 让人们更容易地探索结构化的提交历史，降低贡献项目的难度。
Commit Message 标准格式包括三个部分：Header，Body，Footer
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
Header（必须）
Header 部分只有一行，包括三个字段：type（必需）、scope（可选）、subject（必需）
type
用于说明类型，可分以下几种类型：
| feat | 新功能 |
|---|---|
| fix | Bug 修复 |
| docs | 仅包含文档的修改 |
| style | 格式化变动，不影响代码逻辑 |
| refactor | 重构，既不是新增功能也不是 Bug 修复的代码变动 |
| perf | 提高性能的修改 |
| test | 添加或修改测试代码 |
| build | 构建工具或外部依赖包的修改，比如更新依赖包的版本等 |
| ci | 持续集成的配置文件或脚本的构建 |
| chore | 其他修改 |
| revert | 撤销某次提交 |
scope
用于说明影响的范围，比如数据层、控制层、视图层等等。
subject
主题，简短描述，一行，一般不超过87字符。
Body（推荐）
对 subject 的补充/详细描述，可以多行。
Footer（可选）
BREAKING CHANGE、外部链接、issue 引用和其它元数据信息。
编写规范：
-
使用中文的时候必须使用全角标点符号，使用英文的时候必须使用半角标点符号，中文夹杂英文视同中文；
-
Header ：type 和 scope 必须使用英文，标点符号必须使用半角字符，冒号之后必须加空格，subject 可以使用中文，subject 结尾不应该添加标点符号，例如：feat(login): 添加一键登录功能
-
Body ：无论是单行还是多行，必须使用序号，序号使用阿拉伯数字，紧跟半角句点号和空格，每行结尾不应该添加标点符号，例如：
1. 添加一键登录 Sdk 2. 扩展登录类型 -
在正文结束的一个空行后，可以编写脚注（如果正文缺失，可以编写在描述之后），脚注应当为代码变更包含额外的 issue 引用信息或任务单号，单号用 ID 做为行开头，后面加空格，#号后紧跟单号，也可以是关联多个单号，中间用半角逗号加空格隔开，例如： ID #123，ID #123, #456, #789；
-
破坏性变更必须在提交的正文或脚注加以展示。一个破坏性变更必须包含大写的文本 BREAKING CHANGE，紧跟半角冒号和空格；
-
在 BREAKING CHANGE: 之后必须提供描述，以描述对 API 的变更。例如 BREAKING CHANGE: environment variables now take precedence over config files；
-
Git 用户名使用邮箱登录名，例如：张三邮箱为zhangsan@xxx.com，Git 用户名设置为 zhangsan；
-
以上不符合规范情况，代码审核人员应拒绝合并代码。
打标签
组件发布及应用发布如果需要打标签，规则为：
- 标签名必须是版本号，版本号不加前缀，例如：2.0.0，2.2.0-branch01；
- 标签可选使用附注标签。
