Git 提交消息规范：理解 fix、feature 等关键词的含义
文章目录
-
- 1. 引言
- 2. 提交消息的基本结构
-
- 示例
- 3. 核心关键词解析
-
- 3.1 `fix`
- 3.2 `feat` (feature)
- 4. 其他常用关键词
-
- 4.3 `docs`
- 4.4 `style`
- 4.5 `refactor`
- 4.6 `test`
- 4.7 `chore`
- 4.8 `perf`
- 4.9 `ci`
- 5. 提交消息最佳实践
-
- 5.1 消息格式规范
- 5.2 良好的示例
- 5.3 应避免的示例
- 6. 与语义化版本的关联
- 7. 工具支持
-
- 7.1 Commitizen
- 7.2 commitlint
- 8. 总结
1. 引言
在团队协作的软件开发项目中，清晰、规范的 Git 提交消息对于项目维护至关重要。提交消息中的关键词如 fix、feat 等不仅帮助团队成员快速理解变更内容，还能自动化生成变更日志、确定语义化版本号等。本文档将详细解释这些关键词的含义和使用规范。
2. 提交消息的基本结构
一个规范的 Git 提交消息通常包含三个部分：
<类型>[可选 范围]: <描述>[可选 正文][可选 脚注]
示例
feat(auth): 添加用户登录功能- 实现 JWT 认证
- 添加登录页面组件Closes #123
3. 核心关键词解析
3.1 fix
- 含义：表示修复了一个 bug 或错误
- 使用场景：当提交解决了代码中的缺陷、错误或问题
- 版本影响：通常对应 PATCH 版本号递增（0.0.X）
- 示例：
fix(api): 修复用户注册时邮箱验证失败的问题当用户邮箱包含大写字母时，验证逻辑不正确，现已修复。Fixes #45
3.2 feat (feature)
- 含义：表示添加了一个新功能