· Jeff · 技术文章 · 3 分钟阅读
约定式提交（Conventional Commits）规范速查
一份可直接照做的约定式提交规范：格式、类型、SemVer 对应、破坏性变更标记，附示例。
约定式提交 1.0.0
基于提交信息的轻量级约定，提供一组简单规则来创建清晰的提交历史，便于编写自动化工具。
格式
<类型>[可选 范围]: <描述>
[可选 正文]
[可选 脚注]核心类型与 SemVer 对应
| 类型 | 用途 | SemVer |
|---|---|---|
fix: | 修复 bug | PATCH |
feat: | 新功能 | MINOR |
BREAKING CHANGE | 破坏性 API 变更（脚注或 ! 前缀） | MAJOR |
推荐扩展类型
| 类型 | 用途 |
|---|---|
build: | 构建系统或外部依赖变更 |
chore: | 非业务性代码修改（构建流程、工具配置） |
ci: | 持续集成配置变更 |
docs: | 文档修改 |
style: | 代码样式调整（空格、缩进，不影响逻辑） |
refactor: | 重构（不改变功能） |
perf: | 性能优化 |
test: | 测试用例变更 |
破坏性变更的两种标记方式
方式一：脚注
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files方式二：! 前缀
feat(api)!: send an email to the customer when a product is shipped示例
# 简单修复
fix: prevent racing of requests
# 带范围
feat(lang): add polish language
# 破坏性变更
feat!: drop support for Node 6
BREAKING CHANGE: use JavaScript features not available in Node 6为什么用约定式提交
- 可自动生成 CHANGELOG
- 基于提交类型自动决定版本号（SemVer）
- 结构化提交历史，降低贡献门槛
- 可触发构建和部署流程
常见问题
- 大小写：随意，但保持统一
- 多类型冲突：拆成多次提交
- 写错类型：合并前用
git rebase -i修改；已发布则看工具链 - 不强制所有贡献者使用：squash 工作流下，维护者合并时统一即可
- 还原提交：建议用
revert:类型，脚注引用被还原的提交摘要
☕ 如果这篇文章对你有帮助
欢迎请 Jeff 喝杯咖啡，支持我持续分享更多软件技巧～
打赏功能即将上线，先点个赞也是支持 ❤️
