在PR中可能会遇到的问题
首先非常感谢您对 TDesign 的贡献, 在这边整理了几个常见的可能会遇到的问题，可以供您参考
提交 PR 后，没有通过 CI，我们不会进入 code review 阶段，常见的几个报错如下：
CI 未通过的情况，可以点击进入 CI 详情，看在哪个阶段出现的报错：
如下图是单元测试报错，从单元测试信息可以看到是因为 snapshot 在代码改动后不匹配。
如何解决：我们通过在本地运行 npm run test:update 更新snapshot，改动后的 snapshot 也需要一起提交上来，可以作为 code review 的参考。
该报错问题来源有两种：
- 来自本地代码规范问题，在本地执行
npm run lint自查 - 来自于一些公共依赖的升级后的不兼容，仓库的管理员会第一时间处理好
ci问题，不会超过12小时，可以等待仓库管理员修复好后，再rebase develop或者merge develop。
报错如下：
因为 TD 的每个框架都会依赖于 tdesign-common，所以会存在一个 submodules, 上图的报错原因是把本地的 common 改动提交上来了，但是在远端并没有存在这个 common ref。
查看是否存在子仓库的改动：
在提交 PR 过程中，如果改动到了 _common，则需要走 tdesign-common 的 fork 贡献流程。将本地的改动提交到远端。
单词拼写报错，问题来源有两种：
- 查看报错列表，自查
PR中是否存在报错中的单词拼写问题。忽略关键词配置与忽略文件配置可以写到 typos-config - 来源于
action依赖升级后加入的新规则，可等待仓库管理员处理，
因为 TD 是多个框架共用一套 API, 在您更改 API 之前，请走 API 贡献流程 https://github.com/TDesignOteam/tdesign-api 这或许有些麻烦，但是对于我们的维护工作意义重大。
PR 中的 changlog 是我们发版日志的数据来源，所以尽量描述清楚您本次PR所做的事情，changelog 遵循 Angular提交信息规范，具体示例如下：
-
fix(Compoennt): xxxx (issue #1598)
-
提交类型为
build,ci,fix,feat,docs,pref,refactor,style,test,chore其中之一 -
作用域：一般为组件名，遵循
CamleCase规范 -
更新日志信息：尽量描述清楚您解决的问题，
-
关联issue：需要加上相关联的
issue，具体格式如上