Git 提交规范（Git Commit Message Convention）是为了让项目的提交历史更加清晰、可读、便于追踪和自动化工具解析。常见的规范之一是 Conventional Commits，下面是一个推荐的格式规范：
🌟 提交信息格式（Conventional Commits）
<type>(<scope>): <subject>type：提交类型，必填。scope：影响范围（模块、功能、文件名等），可选。subject：简洁的描述（不超过 50 字符），必填，首字母小写，结尾不加句号。
✅ 常用类型（type）
| 类型 | 描述 |
|---|---|
| feat | ✨ 新功能、新特性 |
| fix | 🐛 修复 bug |
| docs | 📝 文档修改 |
| style | 💄 格式（空格、分号等，不影响逻辑） |
| refactor | 🔨 重构（即不是新功能也不是修复） |
| perf | ⚡ 性能优化 |
| test | ✅ 增加测试 |
| chore | 🔧 构建过程或辅助工具的变动 |
| revert | ⏪ 回退到上一个版本 |
| ci | 🤖 CI/CD 配置 |
| build | 🏗️ 构建系统或依赖变动 |
✍️ 示例
feat(login): 添加用户登录功能
fix(api): 修复 getUser 接口返回 500 的问题
docs(readme): 更新项目启动说明
style: 调整缩进为 4 空格
refactor(auth): 优化权限检查逻辑
test: 增加 login 模块单元测试
chore: 更新 eslint 规则配置💡 推荐约定
- 原子性：每次提交只做一件事。
- 简洁明了 ：
subject不要写太长，描述清楚本次变更做了什么。 - 英文 vs 中文：团队内部可统一用中文或英文，但建议保持一致。
需要我帮你自动生成 Git 提交模版或者写个脚本规范提交信息吗？