如何规范Git commit提交
posts/%E5%A6%82%E4%BD%95%E8%A7%84%E8%8C%83git-commit%E6%8F%90%E4%BA%A4一个规范的 Git commit 能够更有助于开发者更好地合作。对初学者而言意味着通过历史 commit 的信息更方便学习技术的演化。
比如在我最近前端开发所参考的三咲智子的Element Plus Best Practices 最佳实践中就使用了 git 提交规范。
下面我将介绍两个提交规范，一个是Conventional Commits另一个是Angular CONTRIBUTING。
Conventional Commits
提交的信息的结构应如下所示：
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
提交包含以下结构元素，以将意图传达给库的使用者：
- fix：类型为
fix的提交修补了代码库中的错误（与语义版本控制中的PATCH相关）。 - feat：
feat类型的提交为代码库引入了一个新特性（与语义版本控制中的MINOR相关）。 - BREAKING CHANGE：具有页脚
BREAKING CHANGE:的提交，或附加!在 type 或 scope 之后，引入了一个重大的 API 更改（与语义版本控制中的MAJOR相关）。BREAKING CHANGE 可以是任何类型的提交的一部分。 - 允许使用
fix:和feat:以外的类型，例如 @commitlint/config-conventional（基于Angular convention）推荐build:，chore:，ci:，docs:，style:，refactor:，perf:，test:和其他的类型。 - 除了
BREAKING CHANGE: <description>之外的页脚，可以提供并遵循类似于 git trailer 格式的约定。
Angular CONTRIBUTING
Angular CONTRIBUTING 与 Conventional Commits 的提交信息结构相同，只不过是 description 叫法变为了 subject 。
提交的信息的结构应如下所示：
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
结构的部分规定按照如下：
Type
- build: 构建工具变更或外部依赖变更（scopes 举例: gulp， broccoli， npm）
- ci: 持续集成配置文件变更（scopes 举例: Travis， Circle， BrowserStack， SauceLabs）
- docs: 文档变更
- feat: 新功能
- fix: bug 修复
- perf: 代码性能优化
- refactor: 代码重构（不包含 bug 修复和功能添加）
- style: 代码风格变更（不更改代码表述逻辑）
- test: 增加缺失测试用例或修正测试用例
Scope
对于而言视项目架构而定。Angular 将其分为 animations，common，compiler，compiler-cli，core 和 elements 等。
Subject
使用更简洁的描述：
- 使用祈使语气，使用现在时的 change 不是 changed 也不是 changes。
- 首字母不要大写
- 末尾没有 dot 符号
Body
就像在 Subject 中一样，使用祈使式现在时。Body 应该包括变更的动机，并将其与以前的行为进行对比。
Footer
页脚应包含有关重大更改的任何信息，也是引用此提交关闭的 GitHub 问题的地方。
Breaking Changes 应该以BREAKING CHANGE:开头，带有一个空格或两个换行符。然后将提交消息的其余部分用于此目的。具体见此篇文档。
规范工具
- Commitizen （辅助规范 commit 的工具）
- Commitlint （commit 规范格式检查工具）