跳到主要内容

贡献文档

我们的文档根据免费开源许可发布,因此,我们欢迎社区成员的贡献!不过,在贡献你的内容之前,您需要在整个过程中牢记许多事项,以及特定于某些项目的一些细节。

需要牢记的事项

在社交媒体询问他人

例如,如果您不确定某件事是否是一个好主意,如果您不确定如何实现某件事,你可以在我们的 QQ 群进行询问。确保一切无误后再提交 PR。

如果您打算开发新功能、进行重大代码库更改或进行 UI/设计更改,请咨询工作室管理员或者提交 ISSUE,获得许可后再继续你的工作。

不要气馁

有时,拉取请求可能会因各种原因而被拒绝或未合并。不要把他当做针对某人,也不要气馁!有时候一个贡献可能并不适合当前的时机,或者它可能在其他事情的混乱中被遗忘了。你可以按照拒绝原因修改你的 PR,尝试重新提交。归根结底是一件事:不要气馁!

代码并非唯一的贡献方式

我们使用 Docusaurus 部署文档,使用 Markdown 语法进行基本撰写,使用 Github 进行代码托管。或许贡献者对这些工具并不熟悉。没关系,代码并非唯一的贡献方式,你可以在 QQ 群、ISSUE 提出建议,以其他形式投稿你的内容。内容采纳后,我们会将其纳入文档。

Commit 规范

Git 每次提交代码都需要写 commit message,一般来说,commit message 应该清晰明了,说明本次提交的目的,具体做了什么操作。初期我们在互联网上搜索了大量有关 git commit 规范的资料,但只有 Angular 规范是目前使用最广的写法,比较合理和系统化,并且有配套的工具(IDEA 就有插件支持这种写法)。最后综合阿里巴巴高德地图相关部门已有的规范总结出了一套 git commit 规范。

commit message 格式

提示

我们对于 commit 并没有严格的要求,但请尽量遵循这一规范。

<类型>(<范围>): <主题>
类型(必须)描述
feat新功能(feature)
fix/to修复 bug,可以是 QA 发现的 BUG,也可以是研发自己发现的 BUG。
docs文档(documentation)
style格式(不影响代码运行的变动)
refactor重构(即不是新增功能,也不是修改 bug 的代码变动)
perf优化相关,比如提升性能、体验
test增加测试
chore构建过程或辅助工具的变动
revert回滚到上一个版本
merge代码合并
sync同步主线或分支的 Bug
范围(可选)描述
scope用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同
主题(必须)描述
subjectcommit 目的的简短描述,不超过 50 个字符

示例:

fix(DAO):用户查询缺少username属性
feat(Controller):用户查询接口开发

Markdown 规范

提示

我们对于 Markdown 并没有严格的要求,但请尽量遵循这一规范。

点击查阅 Markdown 基本撰写和格式语法

Markdown特性