提交即版本

目录

• type
• 这样的规范能做什么？
• 参考资料

---

Versioning in commit

看到几个个规范文档，理解到其中 commit 即版本的理念

版本号简单来说就是：MAJOR.MINOR.PATCH[-pre-release][+build]

对应到代码更改里面就是：

MAJOR

MAJOR 对应任何向后不兼容的更改，commit 要求如下

在 type 后面添加 ! ，并在 页脚 中添加 BREAKING CHANGE: 描述，例如：

chore!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

MINOR

MINOR 对应任何向后兼容的新功能，commit 要求如下

常见 type 为 feat

feat: allow provided config object to extend other configs

PATCH

PATCH 对应任何向后兼容的 bug 修复，commit 要求如下

常见 type 为 fix、perf、refactor

fix: correct minor typos in code

当然实践中一般不会一个 commit 对应发布一个版本，而是多个 commit 对应一个版本，如果这些 commit 中没有 破坏性更新，那么就发布为 patch 版本；如果有破坏性更新，那么就发布为 MAJOR 版本；如果有新功能，那么就发布为 MINOR 版本。

你可以去看一些仓库的 CHANGELOG.md ，比如：

https://github.com/conventional-changelog/commitlint/blob/master/%40commitlint/config-conventional/CHANGELOG.md

type

• build ：影响构建系统或外部依赖项的更改（示例范围：gulp、broccoli、npm）
• ci ：对我们的 CI 配置文件和脚本的更改（示例范围：Travis、Circle、BrowserStack、SauceLabs）
• docs ：仅文档更改
• feat ：新功能
• fix ：错误修复
• perf ：提高性能的代码更改
• refactor ：既不修复错误也不添加功能的代码更改
• style ：不影响代码含义的更改（空格、格式、缺少分号等）
• test ：添加缺失的测试或更正现有的测试

这样的规范能做什么？

1. 方便自动化（自动生成 CHANGELOG、发布版本）
2. 规范的提交看起来很“专业”，以及在遇到问题时能够更快找到问题
3. 方便交流
4. 方便 AI 理解

参考资料

• Conventional Commits
• 语义版本控制 2.0.0
• angular/CONTRIBUTING.md at 22b96b96902e1a42ee8c5e807720424abad3082a · angular/angular · GitHub | Github