# Pull Request 提交须知

> **TawCorp 内部协作者**：请先阅读 [`doc/development-workflow-zh.md`](doc/development-workflow-zh.md)。该文档定义了从 Multica issue 到 PR 合并到 Deploy Staging 到 QA 验收的端到端流程，以及 agent 角色边界、分支/commit 约定、和不依赖 GitHub branch protection 的软约束模型。下面的通用指南仍然适用，但内部协作以 `doc/development-workflow-zh.md` 为准。

为了确保代码库的质量和项目的可维护性，在提交 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 拆分为更小的逻辑单元。

---

感谢您的贡献！




