Git—commit规范

使用git多人开发时，如果不使用统一的规范则会导致每次更新的内容描述千差万别，不利于多人协作，所以尽量规范commit写法，使内容提交清晰明了

一、为什么需要制定提交规范？

在使用git多人开发时，每个人提交代码都会写到commit message来描述更改的内容

如果每个人有自己的提交风格，则会导致内容百花齐放，不利于维护和后续对接工作等

一般来说大厂都会有自己的commit message规范，来统一提交格式，特别是在大型的开源项目中，格式基本都是统一的

因此，我们需要制定统一标准，促使团队形成一致的代码提交风格，更好的提高工作效率，成为一名有追求的工程师。

二、业界常见的commit规范？

commitizen

AngularJS 在 github上 的提交记录被业内许多人认可，逐渐被大家引用。

格式： type(scoped):subject

( 1 ) type（必须） : commit 的类别，只允许使用下面几个标识：

• feat : 新功能
• fix : 修复bug
• docs : 文档改变
• style : 代码格式改变
• refactor : 某个已有功能重构
• perf : 性能优化
• test : 增加测试
• build : 改变了build工具 如 grunt换成了 npm
• revert : 撤销上一次的 commit
• chore : 构建过程或辅助工具的变动

( 2 ) scope（可选） : 用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

( 3 ) subject（必须） : commit 的简短描述，不超过50个字符。

commitizen 是一个撰写合格 Commit message 的工具，遵循 Angular 的提交规范。

三、适合我们的commit规范

大厂或开源项目所使用的规范相对来说会复杂很多，我们在平常开发中可以仿照其规范，但是精简一些，更加合适

格式： type:description

1.type 类型

type 是 commit 的类别，只允许如下几种标识：

• fix: 修复bug
• add: 新功能
• update: 更新
• style : 代码格式改变
• test: 增加测试代码
• revert: 撤销上一次的commit
• build: 构建工具或构建过程等的变动，如：gulp 换成了 webpack，webpack 升级等
• chore : 构建过程或辅助工具的变动

2.description

description 是对本次提交的简短描述。

构建过程或辅助工具的变动

2.description

description 是对本次提交的简短描述。

不超过50个字符。