良好的提交信息能提升代码可维护性，推荐采用以下规范：
1. 格式模板
<type>(<scope>): <subject>
// 空行
<body>
// 空行
<footer>
2. 核心要素
-
类型(type)：
- ✨
feat：新功能 - 🐛
fix：问题修复 - 📚
docs：文档更新 - 🎨
style：代码样式调整 - 🔧
refactor：重构（不改变功能） - 🚀
perf：性能优化 - ✅
test：测试相关 - 🛠️
chore：构建/工具变更
- ✨
-
作用域(scope)：模块名称（如：user-auth, payment-module）
-
主题(subject)：简明描述（50字内），使用现在时
3. 示例提交
git commit -m "feat(user-auth): 新增双因素认证功能
- 集成Google Authenticator认证模块
- 添加短信验证码备用方案
Closes #123"
4. 各部分详解
(1) Header（标题行）
-
类型（Type）：必填，使用上述固定类型。
-
范围（Scope）：可选，说明改动的影响范围（如模块、组件名称）。例如
feat(api)、fix(auth)。 -
主题（Subject）：简明描述改动目的，首字母小写，结尾不加句号。
(2) Body（正文）
-
详细描述改动内容，可以分条目说明。
-
解释 为什么修改 和 如何实现，而非仅描述代码变化。
-
使用 Markdown 格式（如列表、代码块）。
(3) Footer（页脚）
-
关联 Issue：如
Closes #123、Fixes #456。 -
破坏性变更：用
BREAKING CHANGE:开头，说明不兼容的改动。 -
其他需要备注的信息（如依赖变更）。
5. 最佳实践
- 使用
动词+对象结构：如"增加缓存机制"而非"加了缓存" - 正文每行不超过72字符
- 重大变更需在正文说明
BREAKING CHANGE: - 引用问题追踪编号：
Resolves #ID/Refs #ID
6. 自动化工具推荐
commitlint：提交信息校验commitizen：交互式提交引导standard-version：自动生成CHANGELOG
7. 反例与正例
❌ 错误示例：
-
update code（类型不明确，描述模糊） -
修复了一个 bug（未说明修复内容）
✅ 正确示例：
fix(auth): 解决登录态过期后跳转失败的问题
- 修正 Token 过期后的重定向逻辑
- 添加对应的单元测试用例
Closes #789通过规范化的提交信息，团队协作和代码维护效率会显著提升。建议搭配工具（如 commitlint、husky）自动校验格式。
扫一扫
6929
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
