背景
Git每次提交代码都需要写commit message，否则就不允许提交。一般来说，commit message应该清晰明了，说明本次提交的目的，具体做了什么操作……但是在日常开发中，大家的commit message千奇百怪，中英文混合使用、fix bug等各种笼统的message司空见惯，这就导致后续代码维护成本特别大，业界最终统一规范，形成现在的commit 规范。
规范建设
国内互联网大厂们常用的那一套提交规范现在正在被广泛应用：
<type>(<scope>): <subject>
简介
| 描述 \ 类型 | type | scope | subject |
|---|---|---|---|
| 是否必须 | 必须 | 非必须 | 必须 |
| 用途 | 说明类别 | 说明影响范围 | 简短描述 |
type 常见类型
| 类型 | 解释说明 |
|---|---|
| feat | 新功能（feature） |
| fix | 修复BUG |
| docs | 文档 |
| style | 格式样式（不影响代码运行的变动） |
| refactor | 重构（既不是新增功能，也不是修改 bug 的代码变动） |
| perf | 优化相关，比如提升性能、体验 |
| test | 增加测试 |
| chore | 构建过程或辅助工具的变动 |
| revert | 归滚到上一个版本 |
| merge | 代码合并 |
| sync | 同步主线或分支的 Bug |
scope(可选)
scope 用于说明 commit 的影响范围，比如数据层、控制层、视图层，根据项目不同而定。
如果你的修改影响了不止一个 scope，你可以用 * 替代。
subject（必须）git commit -m "docs(README): 更新说明文档，添加项目启动指南"
subject 是 commit 中对于项目修改的简短描述，字符控制在 50 内
- 结尾不加标点符号
commit 示例
git commit -m "fix(login): 修复了登录表单密码校验的bug"git commit -m "style(navbar): 更新导航栏样式"git commit -m "feat(chat): 新增聊天功能"git commit -m "chore(vite): 更新了 vite 版本"git commit -m "docs(README): 更新说明文档，添加项目启动指南"
规范意义
来自 AI 的答案：
- 提高可读性：规范化的commit信息使得版本历史更加清晰易读。其他开发者（包括未来的你）可以快速理解每次更改的目的和范围，而不需要深入查看代码细节。
- 便于跟踪：当项目中出现问题时，规范的commit信息可以帮助快速定位引入问题的更改。这对于bug跟踪和回滚至某个稳定版本特别有用。
- 自动化支持：遵循一定的规范可以为自动化工具提供支持。例如，可以基于commit信息自动生成版本日志，自动判断版本号的变化（如根据feat和fix标签区分新功能和修复），以及自动化构建和部署。
- 改进团队协作：当所有团队成员都遵循同一套commit规范时，可以减少沟通成本，提高团队协作效率。这种一致性确保每个人都能快速理解他人的更改，有助于维护一个健康的代码库。
- 促进公共理解：对于开源项目，规范的commit信息可以帮助社区成员理解项目的发展历程和每次更改的背景，这对于吸引和保留贡献者至关重要。
- 提升专业性：遵守业界公认的最佳实践，如约定式提交（Conventional Commits），能够提升项目和开发者的专业形象，这在开源社区或寻求职业发展时尤为重要。
