关于Git仓库提交规范说明
1.前言
在初学者使用 Git 提交代码时，往往会出现提交信息随意、语义不清的问题。这种方式在项目初期影响不大，但随着项目规模扩大，会导致提交历史难以追溯、问题定位困难、协作成本增加。
常见的 Git 仓库提交规范主要是为了让提交历史清晰、可读、可维护。业界最常用的一套是Conventional Commits（约定式提交），很多团队也会在此基础上做轻微定制。本文浅尝辄止地讲解一下代码提交的基本规范，以帮助快速上手Git这个强大的版本管理工具。
Conventional Commits官方网站：
Conventional Commits
2.提交信息基本结构
<type>(optional scope): <subject>
[optional body]
[optional footer]
3.type（提交类型）
最核心的一部分，用来说明这次提交的性质：
| 类型 | 含义 |
| feat | 新功能 |
| fix | 修复 bug |
| docs | 文档变更 |
| style | 格式调整（不影响代码逻辑） |
| refactor | 重构（既不是新功能也不是修复） |
| perf | 性能优化 |
| test | 测试相关 |
| chore | 构建/工具/依赖变更 |
| ci | CI/CD 相关 |
| build | 构建系统或依赖变更 |
| revert | 回滚 |
4.optional scope（可选）
表示影响范围（模块/功能）：
feat(auth): 登录支持验证码
fix(api): 修复用户接口报错
5.subject（提交标题）
规范：
- 使用动词开头
- 使用现在时
- 不超过 50 字符
- 不加句号
示例：
feat: 添加用户注册功能
fix: 修复登录状态丢失问题
6.body（可选详细说明）
用于解释“为什么改”，而不是“改了什么”
示例：
fix: 修复支付重复提交问题
由于前端未做防抖处理，用户快速点击会导致重复请求，
在服务端增加幂等性校验。
7.footer（可选）
用于：
1. 关联 issue
Closes #123
2. BREAKING CHANGE（重大变更）
BREAKING CHANGE: 登录接口返回结构已修改
8.完整示例
feat(user): 增加用户头像上传功能
支持 jpg/png 格式，限制大小为 2MB，
并接入对象存储服务。Closes #45