提交与 PR 协作规范
1. 分支策略
- 永远从最新
main拉新分支 - 一个分支只做一类改动（一个主题/一个功能/一个修复）
- 分支命名建议：
fix/...feat/...chore/...docs/...
2. 提交前检查
bash
yarn lint
yarn type-check
yarn test如果改动涉及构建链路，建议额外执行：
bash
yarn build3. 提交规范
推荐 Conventional Commits：
feat(scope): ...fix(scope): ...docs(scope): ...chore(scope): ...
4. PR 内容建议模板
- 背景/问题
- 方案说明（为什么这么做）
- 改动范围（文件列表）
- 风险与兼容性评估
- 验证步骤（本地命令 + 结果）
5. 明确禁止项（减少冲突）
- 不要把个人
.env.local提交到仓库 - 不要提交与你任务无关的个性化
config.js改动 - 不要把多个无关功能塞进同一个 PR
- 不要在主分支直接提交开发改动
6. 对评审者友好的做法
- 尽量做“最小补丁”
- 大改动拆分为多个小 PR
- 在 PR 描述中标注“是否包含破坏性变更”
7. 用户文档（user-guide）
修改或新增 docs/user-guide/ 时，请遵循 文档维护工作流：同步更新 README.md、ARTICLE_INDEX.md，并与 conf/*.config.js 中的配置键保持一致。