Day47 代码提交规范

代码提交规范

type 提交类型(required)

每个提交都必须使用类型字段前缀，它由一个名词组成，诸如 feat 或 fix ，其后接一个可选的作用域字段，以及一个必要的冒号（英文半角）和空格。

feat：当一个提交为应用或类库实现了新特性时，必须使用 feat 类型
fix：当一个提交为应用修复了 bug 时，必须使用 fix 类型
docs：只修改了文档
style：做了不影响代码含义的修改，空格、格式化、缺少分号等等
refactor：进行代码重构，既不是修复bug，也不是新功能的修改
perf：改进性能的代码
test：增加测试或更新已有的测试
chore：构建或辅助工具或依赖库的更新

例如：

feat: 增加年审工单
fix: 修复运维类请款单页面内存泄漏的问题
chore(release): AMS V2.18.0

scope 范围

作用域字段可以跟随在类型字段后面。作用域必须是一个描述某部分代码的名词，并用圆括号包围，例如： fix(parser)

description 描述(required)

描述字段必须紧接在类型/作用域前缀的空格之后。描述指的是对代码变更的简短总结，例如： fix: array parsing issue when multiple spaces were contained in string.

body 正文

在简短描述之后，可以编写更长的提交正文，为代码变更提供额外的上下文信息。正文必须起始于描述字段结束的一个空行后。

footer 页脚注释

在正文结束的一个空行之后，可以编写一行或多行脚注。脚注必须包含关于提交的元信息，例如：关联的合并请求、Reviewer、破坏性变更，每条元信息一行。

BREAKING CHANGE 破坏性变更

• 破坏性变更必须标示在正文区域最开始处，或脚注区域中某一行的开始。一个破坏性变更必须包含大写的文本 BREAKING CHANGE，后面紧跟冒号和空格。
• 在 BREAKING CHANGE: 之后必须提供描述，以描述对 API 的变更。例如： BREAKING CHANGE: environment variables now take precedence over config files.

FAQ

一次提交多种类型怎么操作？

尽可能拆分的task，每完成一部分就进行一次提交，避免一次提交过多的代码。这样能够避免一次commit修改过多文件，导致后续的维护，回退等的困难。
如果真的有这样的提交，可以选择最重要改动的type，在body部分详细写明具体的改动。

参考：

约定式提交规范
你见过最奇葩的代码提交信息是什么？别再为写commit message头疼了！