Gitee 提交信息的规范

在使用 git push 命令将代码推送到 Gitee（或任何 Git 平台）时，引号中的信息通常指的是 提交信息（Commit Message）。提交信息是对本次代码修改的简要描述，规范的提交信息有助于团队协作和版本管理。

Gitee 提交信息的规范

虽然 Gitee 本身没有强制格式，但社区普遍遵循以下最佳实践：

1. 结构化格式（推荐）

采用 标题行 + 空行 + 详细描述 的结构：

<类型>: <简短描述>
<空行>
<详细描述：解释修改原因、影响范围等>

• 类型（Type）：常见的类型包括：
  • feat：新功能
  • fix：修复 bug
  • docs：文档更新
  • style：代码格式调整（不影响功能）
  • refactor：代码重构
  • test：添加或修改测试
  • chore：构建流程或辅助工具的变动

示例：

fix: 修复登录页面验证码不刷新的问题- 原因：验证码生成逻辑未正确处理缓存
- 解决方案：每次请求时添加时间戳参数
- 影响范围：仅登录模块

2. 简短描述的注意事项

• 使用祈使句：用动词开头，如 Add feature 而非 Added feature 或 Adds feature。
• 保持简短：标题行建议不超过 50 个字符。
• 明确目的：避免模糊的描述（如 更新代码），尽量具体（如 修复用户注册时的邮箱格式验证）。

3. 详细描述的建议

• 解释动机：说明为什么做这个修改，而不是简单描述修改内容。
• 技术细节：必要时提供实现思路或技术方案。
• 关联 issue：如果有对应的 Gitee Issue，可以在提交信息中引用（如 Closes #123）。

Gitee 特有的规范

Gitee 支持通过提交信息自动关闭 Issue，格式为：

<类型>: <描述>Closes #123  <!-- 合并后自动关闭编号为 123 的 Issue -->
Fixes #456   <!-- 修复了编号为 456 的 Issue -->

工具推荐

为了确保提交信息规范，可以使用以下工具：

1. Commitizen：交互式提交工具，引导你生成符合规范的提交信息。
2. Commitlint：校验提交信息格式，集成到 CI/CD 流程中防止不规范的提交。

示例对比

遵循这些规范可以让你的提交历史更清晰，便于团队成员理解和维护代码。如果团队有特定的规范，建议优先遵循团队约定。