Appearance
命名规范
在为一个资源起名称的时候，应该本着描述性以及唯一性这两大特征来命名，才能保证资源之间不冲突，并且每一个都便于记忆。命名规范要望文知义，简单明了。
文件夹：全部英文小写字母 + 数字或连接符 -
命名严谨性
代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。
说明：正确的英文拼写和语法可以让阅读者易于理解，避免歧义。注意，即使纯拼音命名方式也要避免采用。
- 正例：
henan、luoyang、rmb等国际通用的名称，可视同英文。 - 反例：
DaZhePromotion[打折] 、getPingfenByName[评分]
项目命名
全部采用小写方式， 以中划线 - 分隔：
- 正例：
my-project - 反例：
my_project、myProject
目录命名
参照项目命名规范。有复数结构时，要采用复数命名法，缩写不用复数：
- 正例：
scripts、styles、components、images、utils、demo-styles、demo-scripts、img - 反例：
script、style、demo_scripts、demoStyles、imgs
文件命名
JS、CSS、Less、SCSS、HTML、图片文件命名
采用小写方式， 以 - 分隔：
- 正例：
render-dom.js、reset.css、index.html、company-logo.png - 反例：
UserManagement.html
vue、jsx、tsx 文件命名 可能有争议
采用小写方式， 以-分隔：
- 正例：
index.vue、index.jsx、index.tsx、hello-world.vue、hello-world.tsx - 反例：
UserManagement.vue
NPM 包规范
CSS 规范
JS 规范
HTML 规范
Git 规范
开发流程
- 从保护分支（通常是
main）创建新的功能分支 - 在新分支上进行开发
- 提交 Pull Request 到目标分支
- 等待 Code Review 和 CI 通过
- 合并到目标分支
分支命名规范
- 功能开发：
feat/description-of-feature- 例如：
feat/add-dark-mode - 例如：
feat/improve-table-performance
- 例如：
- 问题修复：
fix/issue-number-or-description- 例如：
fix/button-style-issue - 例如：
fix/issue-1234
- 例如：
- 文档更新：
docs/what-is-changed- 例如：
docs/update-api-reference - 例如：
docs/fix-typos
- 例如：
- 代码重构：
refactor/what-is-changed- 例如：
refactor/button-component - 例如：
refactor/remove-deprecated-api
- 例如：
- 样式修改：
style/what-is-changed- 例如：
style/update-button-tokens - 例如：
style/improve-mobile-layout
- 例如：
- 测试相关：
test/what-is-changed- 例如：
test/add-button-test - 例如：
test/improve-coverage
- 例如：
- 构建相关：
build/what-is-changed- 例如：
build/upgrade-webpack - 例如：
build/fix-ts-config
- 例如：
- 持续集成：
ci/what-is-changed- 例如：
ci/add-e2e-test - 例如：
ci/fix-deploy-script
- 例如：
- 性能优化：
perf/what-is-changed- 例如：
perf/optimize-render - 例如：
perf/reduce-bundle-size
- 例如：
- 依赖升级：
deps/package-name-version- 例如：
deps/upgrade-react-19 - 例如：
deps/update-dependencies
- 例如：
分支命名注意事项
- 使用小写字母
- 使用连字符（-）分隔单词
- 简短但具有描述性
- 避免使用下划线或其他特殊字符
- 如果与 Issue 关联，可以包含 Issue 编号
Pull Request 规范
PR 标题
- PR 标题始终使用英文
- 遵循格式：
类型: 简短描述 - 例如：
fix: fix button style issues in Safari browser - 例如：
feat: add dark mode support
PR 内容
- PR 内容默认使用英文
- 尽量简洁清晰地描述改动内容和目的
- 可以视需要在英文描述后附上中文说明
PR 提交注意事项
审核流程：
- PR 需要由至少一名维护者审核通过后才能合并
- 确保所有 CI 检查都通过
- 解决所有 Code Review 中提出的问题
PR 质量要求：
- 确保代码符合项目代码风格
- 添加必要的测试用例
- 更新相关文档
- 大型改动需要更详细的说明和更多的审核者参与
工具标注：
- 如果是用 Cursor 提交的代码，请在 PR body 末尾进行标注：
> Submitted by Cursor
- 如果是用 Cursor 提交的代码，请在 PR body 末尾进行标注：