博客

1. Commit信息编写规范 ​

1.1 基本格式 ​

<type>[optional scope]: <description>

1.2 类型说明 ​

• feat: 新功能
• fix: 修复缺陷
• docs: 文档更新
• style: 代码格式调整（不影响功能）
• refactor: 代码重构
• perf: 性能优化
• test: 测试相关
• chore: 构建过程或辅助工具变动
• ci: CI 配置变更
• build: 构建系统或外部依赖变更

1.3 编写要求 ​

• 使用祈使句，现在时态（如："fix"而非"fixed"或"fixes"）
• 首字母小写，不以句号结尾
• 描述要简洁明了，说明提交目的

1.4 示例 ​

# 良好示例
feat(auth): 添加OAuth2.0登录支持
fix(api): 修复分页查询参数验证问题
docs: 更新API接口文档

# 不良示例
fixed bug
更新代码
小修改

2. PR编写规范 ​

2.1 PR提交前自查清单 ​

• [ ] Commit信息符合规范
• [ ] PR标题清晰准确
• [ ] 关联了正确的Issue
• [ ] 代码变更单一专注
• [ ] 测试用例完备
• [ ] 文档更新及时
• [ ] 发布说明填写完整

2.2 PR提交规范 ​

2.2.1 标题规范 ​

• 格式：<type>[scope]: 简要描述
• 清晰描述PR的主要内容

2.2.2 内容规范 ​

提交PR时可参考以下模板填写，确保变更信息清晰完整，便于代码审查和后续追溯。

# 标题  feat：检查集群名称是否符合命名规范
# 问题背景 
（简述问题/需求的出现背景以及内容变更的必要性。）
示例：集群创建前需要检查集群名称是否符合命名规范，避免创建非法名称的集群。

# PR类型
（可选：修复问题/实现需求/文档更新/其他任务）
示例：实现需求

# 变更内容
## 变更描述
（分点描述变更涉及的具体变更点）
示例：
- 新增 ValidateClusterName 方法，校验集群名称格式
- 在 CreateCluster 中调用该方法，校验失败时返回错误

## 发布说明
（描述影响的模块/功能、是否有破坏性变更、是否需要更新文档等）
示例：新增校验逻辑，不影响已有正常集群创建

# 备注
（其他相关需要说明的内容）

2.3 PR内容要求 ​

使用PR模板填写所有必填项

2.3.1 PR类型 ​

明确选择对应的类型标签：

• /kind bug - 修复问题
• /kind feature - 实现需求
• /kind documentation - 文档更新
• /kind task - 其他任务

2.3.2 变更描述 ​

• 清晰说明PR的目的和内容
• 使用1、2、3点式罗列主要变更
• 说明变更的动机和背景

2.3.3 发布说明 ​

• 无用户影响：填写NONE"
• 有用户影响：详细描述变更内容
• 如需用户操作：包含"action required"

2.4 PR可追溯性要求 ​

2.4.1 Issue与PR关联要求 ​

每个PR必须关联以下类型Issue之一：

• 问题单（Bug Issue）
• 需求单（Requirement Issue）
• 其他相关 Issue

说明：

• 如果没有相关Issue，则需要先创建Issue，单击查看Issue编写规范。
• 关联PR和Issue时请使用Issue页面右侧的“关联PR”功能

2.5 保持PR内容干净 ​

2.5.1 单一职责原则 ​

• 一个PR只解决一个问题或实现一个功能
• 避免在一个PR中混合多个不相关的修改

2.6.2 Commit整理建议 ​

建议提交前进行如下操作:

1. Rebase 主分支：确保基于最新代码

   bash

   git fetch origin
   git rebase origin/main

2. 整理commit历史：

   bash

   # 合并多个相关的小commit
   git rebase -i HEAD~3
   
   # 或者使用 squash 合并
   git commit --amend

禁止的情况：

• 一个PR包含多个"fix: issue"的commit
• 包含无关的格式调整或空白字符修改
• 将多个独立功能混合在一个PR中

3. Issue编写规范 ​

3.1 问题单（Bug）编写要求 ​

使用template_bug.md模板

3.1.1 标题格式 ​

【模块名称】问题简要描述

示例：【应用市场】应用详情页面加载失败

3.1.2 环境信息 ​

• 详细描述复现环境
• 操作系统、版本、架构等信息

3.1.3 问题描述 ​

• 清晰描述问题现象
• 提供详细的复现步骤
• 包含期望结果和实际结果对比

3.1.4 Issue关联 ​

• 推荐附上在release-management中的需求链接

3.2 需求单（Requirement）编写要求 ​

使用template_requirement.md模板

3.2.1 需求描述 ​

• 背景和使用场景说明
• 需求的价值和竞争力分析
• 明确的需求类型（新增/增强/继承）

3.2.2 约束条件 ​

• 兼容性要求
• 技术约束
• 交付时间和团队信息

4. Issue关闭规范 ​

4.1 手动关闭条件 ​

以下情况可以手动关闭：

• 问题无法复现且提供足够信息
• 问题属于预期行为
• 问题或需求已通过关联的PR解决
• 重复问题 <Issue URL>
• 需求已由其他方式实现
• 需求不再适用

手动关闭Issue需要提供说明

4.2 关闭前检查清单 ​

• [ ] 问题已修复并验证
• [ ] 相关测试用例已添加
• [ ] 文档已更新（如需要）
• [ ] 发布说明已填写
• [ ] 相关PR已合并

4.3 关闭评论规范 ​

关闭评论时需按照以下格式填写，确保问题关闭原因清晰可追溯。

# 关闭评论
已通过PR <PR URL>修复该问题，验证结果：
- 修复版本：v1.2.0
- 验证环境：测试环境
- 验证结果：分页查询性能提升10倍
- 相关 PR：<PR URL>

关闭此问题。