Git提交规范
1. 什么是Git提交规范
Git提交规范是一种约定俗成的提交信息编写标准，旨在使代码仓库的提交历史更加清晰、可读和有组织。良好的提交规范能够帮助团队更好地追踪项目变更，促进协作和代码管理。
2. 提交信息的基本结构
一个标准的Git提交信息通常包含三个主要部分：
- 标题（Type）
- 描述（Optional）
- 页脚（Optional）
2.1 提交信息模板
<type>(<scope>): <subject><body><footer>
3. 提交类型（Type）
常见的提交类型包括：
feat: 新功能fix: 修复bugdocs: 文档变更style: 代码格式调整（不影响代码功能）refactor: 重构代码test: 添加或修改测试chore: 构建过程或辅助工具的变更
示例
feat(user-login): 新增短信验证登录功能
fix(payment-module): 修复支付超时bug
docs(readme): 更新项目安装说明
4. 作用域（Scope）
作用域用于说明本次提交影响的范围，通常是模块、组件或功能点的名称。
好的作用域示例
(user-module)(payment-service)(frontend)(backend)
5. 提交描述（Subject）
提交描述应该简洁明了，使用祈使语气，首字母小写。
正面案例
- “添加用户注册功能”
- “修复登录页面样式错误”
- “优化数据库查询性能”
反面案例
- “Added user registration” (不够简洁)
- “fixed some bugs” (过于笼统)
6. 详细描述（Body）
在更复杂的提交中，可以添加详细的变更描述，解释为什么要做这个变更。
示例
feat(user-module): 新增用户角色管理功能实现了以下需求：
- 支持创建和编辑用户角色
- 添加角色权限控制
- 优化角色管理界面交互
7. 页脚（Footer）
页脚通常用于关联issue、说明重大变更或标注破坏性变更。
示例
fix(authentication): 修复token过期问题关闭 #123 issue
BREAKING CHANGE: 重构了认证流程，需要更新客户端
8. 推荐工具
8.1 Git Commit Message 校验工具
- commitlint
- husky
8.2 自动生成变更日志
- conventional-changelog
- standard-version
9. 最佳实践
- 保持提交信息的简洁和描述性
- 一个提交应该只做一件事
- 使用英语编写提交信息
- 避免模糊不清的描述
- 定期回顾和改进团队的提交规范
——运行时数据区)
