Git Comments 提交规范

• 1. 提交信息格式
• 2. 常用提交类型
• 3. 提交信息示例
  • 示例 1：新增功能
  • 示例 2：修复 bug
  • 示例 3：文档更新

Git 代码提交规范对于团队协作和项目维护至关重要，它能够确保提交历史清晰、可追溯，便于后续的代码审查、问题追踪以及版本发布。以下是一些常见的 Git 代码提交规范和最佳实践：

1. 提交信息格式

一个完整的提交信息通常包含三个部分：标题（Header）、正文（Body） 和 页脚（Footer），各部分之间用空行分隔。

<类型>(<范围>): <简短描述>
// 空行
[可选] 详细描述
// 空行
[可选] 关联的 Issue 或 Breaking Change

• 标题（Header）：
  • 类型（Type）：必须，描述提交的类型（如 feat、fix、docs 等）。
  • 范围（Scope）：可选，说明修改的具体模块或功能（如 user、api、ui 等）。
  • 简短描述（Description）：必须，用简洁的语言概括变更内容（不超过 50 个字符，首字母小写，结尾不加标点）。
• 正文（Body）：
  • 可选，详细说明修改的动机、背景和实现细节，每行不超过 72 个字符。
• 页脚（Footer）：
  • 可选，用于关联 Issue（如 Fixes #123）或声明重大变更（如 BREAKING CHANGE: ...）。

2. 常用提交类型

以下是常见的提交类型及其含义：

3. 提交信息示例

示例 1：新增功能

feat(user): 添加用户注册验证码功能

新增了验证码生成、发送和验证逻辑，
使用 Redis 存储验证码，有效期 5 分钟。

Fixes #456

示例 2：修复 bug

fix(api): 修复用户登录时密码加密错误

由于密码加密算法使用错误，导致部分用户无法登录。
现已更正为使用 bcrypt 进行加密。

Fixes #789

示例 3：文档更新

docs: 更新 API 文档中的用户接口说明

补充了用户注册、登录和获取信息接口的参数说明，
添加了错误码对照表。

遵循这些规范可以让你的 Git 提交历史更加清晰、专业，提高团队协作效率。根据项目需求，你可以在此基础上调整或扩展规范。

原文链接：Git Comments 提交规范，转载请注明来源！