45 lines
1.6 KiB
Markdown
45 lines
1.6 KiB
Markdown
# Pull Request 提交须知
|
||
|
||
为了确保代码库的质量和项目的可维护性，在提交 Pull Request（PR）之前，请务必遵循以下准则：
|
||
|
||
## 1. PR 标题和描述
|
||
|
||
- **标题清晰**：简明扼要地描述 PR 的主要内容，例如：
|
||
- Fix: 修复用户登录时的错误提示
|
||
- Feature: 添加订单导出功能
|
||
|
||
- **描述详细**：在描述中包括以下内容：
|
||
- 此 PR 的目的和背景。
|
||
- 变更的详细说明。
|
||
- 如果涉及 Bug 修复，需描述问题重现的步骤。
|
||
- 如果涉及新功能，需描述其使用方式。
|
||
- 关联的 Issue（如有），使用关键字关闭 Issue，例如：`Closes #123`。
|
||
|
||
## 2. 提交代码前的检查
|
||
|
||
- **代码风格**：确保代码符合项目的代码规范。
|
||
- **功能测试**：对新功能或 Bug 修复进行全面测试，确保没有功能缺失或回归问题。
|
||
- **单元测试**：为新增或修改的功能编写单元测试，并确保所有测试通过(工具类即`pkg/*`下面的必须带有单元测试)。
|
||
- **文档更新**：如果 PR 涉及新功能或接口更改，确保文档同步更新。
|
||
|
||
## 3. 分支策略
|
||
|
||
- **正确的分支**：
|
||
- 新功能应基于 `feature/*` 分支进行开发。
|
||
- Bug 修复应基于 `fix/*` 分支。
|
||
- 确保 PR 的目标分支与项目的分支策略一致。
|
||
|
||
- **同步主干代码**：在提交 PR 之前，请确保分支已经与目标分支（develop）同步。
|
||
|
||
## 4. 审查流程
|
||
|
||
- **小型提交**：避免一次性提交过多的更改，将 PR 拆分为更小的逻辑单元。
|
||
|
||
---
|
||
|
||
感谢您的贡献！
|
||
|
||
|
||
|
||
|