消息格式
每个提交消息都由一个标题、一个正文和一个页脚组成。而标题又具有特殊格式，包括修改类型、影响范围和内容主题：
1 | 修改类型(影响范围): 标题 |
标题是强制性的，但标题的范围是可选的。
修改类型
每个类型值都表示了不同的含义，类型值必须是以下的其中一个：
- feat：提交新功能
- fix：修复了bug
- docs：只修改了文档
- style：调整代码格式，未修改代码逻辑（比如修改空格、格式化、缺少分号等）
- refactor：代码重构，既没修复bug也没有添加新功能
- perf：性能优化，提高性能的代码更改
- test：添加或修改代码测试
- chore：对构建流程或辅助工具和依赖库（如文档生成等）的更改
代码回滚
代码回滚比较特殊，如果本次提交是为了恢复到之前的某个提交，那提交消息应该以“revert:”开头，后跟要恢复到的那个提交的标题。然后在消息正文中，应该写上“This reverts commit
影响范围
范围不是固定值，它可以是你提交代码实际影响到的任何内容。例如$location、$browser、$compile、$rootScope、ngHref、ngClick、ngView等，唯一需要注意的是它必须足够简短。
当修改影响多个范围时，也可以使用“*”。
标题
标题是对变更的简明描述：
- 使用祈使句，现在时态：是“change”不是“changed”也不是“changes”
- 不要大写首字母
- 结尾不要使用句号
正文
正文是对标题的补充，但它不是必须的。和标题一样，它也要求使用祈使句且现在时态，正文应该包含更详细的信息，如代码修改的动机，与修改前的代码对比等。
页脚
任何Breaking Changes（破坏性变更，不向下兼容）都应该在页脚中进行说明，它经常也用来引用本次提交解决的GitHub Issue。
Breaking Changes应该以“BREAKING CHANGE:”开头，然后紧跟一个空格或两个换行符，其他要求与前面一致。
智能校园安全物联平台(Intelligent campus security IoT platform)
分支功能描述
master: 长期分支，用于对外版本发布，所有版本出自此版本库。此分支不允许直接提交代码，只从bugfix分支和develop分支合并。
develop: 长期分支，用于日常代码开发，与master分支 保持同步，当新功能开发完成后线合并到此分支，经过测试后再合并到master分支。
bugfix: 临时分支，当出现bug时基于master分支新建bugfix/bug-1,bug分支可根据bug编号命名。bug测试完毕合并进入develop分支和master分支
feature: 临时分支，开发新功能时从develop分支新建feature/feature-1,feature分支可根据功能命名。新特性开发完成合并进入develop分支并删除feature分支。
release: 临时分支，需要发布版本时从master分支新建release/release-1.0.0,release分支根据版本号命名。
release分支禁止再合并功能，只提交bug修改，版本发布完成后合并进入master和develop，并再对应的提交上打版本Tag。
提交规范
参考格式
1 | <type>: <subject> |
type: 本次commit的类型，如bugfix,docs,style等
feat: 添加新特性
fix: 修复bug
docs: 修改文档
style: 修改格式缩进,不改变代码逻辑
refactor: 代码重构,没有添加新下功能或者修复bug
perf: 增加代码进行性能测试
test: 增加测试用例
chore: 改变构建流程或者增加依赖库、工具等
scope: 本次commit波及范围
subject: 简明扼要阐述本次commit的主旨
- 使用祈使句
- 首字母不要大写
- 结尾无需添加标点
body: 详细描述本次commit,如需换行则使用
|footer: 描述下与之关联的 issue 或 breadk change
标题行： 50个字符以内，描述主要变更内容
主体内容: 更详细下说明文本，建议72个字符以内。需要描述信息包括：
- 为什么这个变更是必须的，它可能是用来修复一个bug，增加一个feature,提升性能、可靠性、稳定性等
- 如何解决这个问题，具体描述解决问题的步骤
- 是否存在副作用、风险
如果需要的话可以添加一个连接到issue或其他文档
示例
1 | docs(README): README添加代码提交规范 |
