介绍

为了提高openHiTLS代码仓库的可读性和维护性，我们制定了以下 Git 提交信息的书写规范。请所有贡献者在提交代码时遵循此规范。

提交信息结构

提交信息应分为以下几个部分：

• 标题（Subject）：简短描述提交的主要内容，50 字符以内。
• 正文（Body，可选）：详细说明提交的背景、原因或改动细节，按需提供。
• 页脚（Footer，可选）：记录关联的 Issue、PR 或其他元信息。

示例：

feat: add user authentication module

- Implement JWT-based authentication
- Add login and logout endpoints
- Update user model with token field

Closes #123

标题规范

格式：类型(范围): 简短描述

• 类型：表明提交的性质，常用类型包括：
  • feat：新功能
  • fix：修复 Bug
  • docs：文档变更
  • style：代码格式调整（不影响逻辑）
  • refactor：代码重构（无新功能或 Bug 修复）
  • test：添加或修改测试
  • chore：杂项（如更新依赖、配置等）
• 范围：可选，指定影响的模块或功能（如 auth、ui、api）。
• 描述：使用动词开头，首字母小写，简洁清晰，无需句号结尾。

示例： fix: resolve login issue in auth module

正文规范

• 使用短语或项目符号列出具体变更。
• 提供提交的背景、目的或技术细节。
• 保持简洁，重点突出。

示例：

- Add input validation for login form
- Fix token refresh logic
- Update error handling for API responses

页脚规范

• 引用关联的 Issue 或 Pull Request，如 Closes #123 或 Related to #456。
• 可添加其他元信息，如合著者（Co-authored-by: Name <email>）。

示例：

Closes #123
Co-authored-by: Jane Doe <jane@example.com>

注意事项

• 清晰性：避免模糊描述，如“fix bug”应改为“fix null pointer exception in user service”。
• 原子性：一个提交只解决一个问题，一个PR内应避免多个冗余重复的Commit（合并为一个）。
• 语言：使用英文书写，确保国际化团队可理解。
• 长度：标题控制在 50 字符以内，正文尽量不超过 72 字符每行。
• 时态：使用现在时态，如 add 而不是 added。

示例提交信息

feat(x509): add x509 certificate module

- Support parsing and encoding x509 certificate 
- Intergrated x509 into tls 

Closes #42

示例可参考：https://www.conventionalcommits.org/zh-hans/v1.0.0/

7. 常见问题

Q：如何处理修复多个 Bug 的提交？

A：将每个 Bug 修复拆分为单独的提交，或在正文中列出所有修复的 Bug 编号。

Q：如果提交很小，是否需要正文？

A：小型变更可省略正文，但标题需清晰描述改动。

通过遵循此规范，我们可以确保提交历史清晰、易于追溯，并便于协作和代码审查。