适合自己的才是最好的。
在使用 Git 进行团队协作和代码版本控制时，良好的 Git 提交规范，可以提高团队协作效率和项目管理质量。以下内容从代码提交和提交信息两个方面，讨论规范的可行性，不涉及具体的 Git 命令。
1. 代码提交规范
1.1. 每个提交应专注于解决一件事情
如修复一个 Bug、新增一项功能，这样方便单个任务的 Code Review ，也有利于跨分支单个功能合并。如果单个任务较重，也可以拆分为多个提交。
1.2. 合并一个任务的多次提交
对于一个任务多次提交的场景，在任务完成后，应该将这些提交合并为一个完整提交，避免 Git 提交历史交叉混乱。
1.3. 避免提交非必要代码
在实际开发过程中，可能会在本地添加一些临时的调试代码或验证性代码，但在最终提交时，应该去除此类代码，确保只提交符合需求的有效代码。
2. 提交信息规范
2.1. 提交信息格式
type: subject
body
type：提交类型，通常是一个动词或名词。
subject：简短描述提交内容。
body：（可选）更详细的说明，描述提交背景、解决的问题或影响的范围。
2.2. 常用提交类型
| Type | 说明 |
|---|---|
| init | 初始化项目 |
| feat | 新功能 |
| update | 对已有功能的更新或增强，通常是 feat 类型的改进 |
| fix | 问题修复，主要用于修复生产环境 Bug |
| refactor | 重构代码，不改变功能，主要是代码结构和性能优化 |
| style | 代码样式更改，如格式化、添加注释或日志 |
| test | 测试相关，如单元测试 |
| build | 系统构建或依赖项的更改，如升级依赖版本、修改构建脚本 |
| revert | 撤销或回滚某次提交 |
| doc | 文档更改，如README、SQL 文件 |
2.3. 提交内容建议
使用动词前缀，如添加、修复、优化、完善等，明确具体操作和内容。
对于复杂功能或重要修复：可在 body 中简述问题背景和解决思路，帮助成员了解上下文信息。
不推荐
fix: 登录异常修复
推荐
fix: 修复用户登录时的空指针异常
