说明

感谢参加编辑！

下面的内容将指导您如何参与到本文档的写作中，每一个细小的贡献，都是值得肯定和鼓励的。

为了参与编写，你需要注册一个 GitHub 账号。如果你没有，请在这里注册。

使用本地编辑器

编写前请先使用 git pull 拉取最新版本。

外链的添加

如果您想添加外链，需要提交 PR 。Readme 的外链由仓库维护者自行添加，不接受 PR. 对于贡献者，添加外链需要满足以下条目：

内容要求

具有一定时效性
内容主题符合 Wiki 内容，且内容不带有明显商业推广。

访问

材料须可备份（如网页转 PDF 等）或提供透明原始材料的下载。
必须可公开查看。

格式要求

准确明白为第一，覆盖度第二。

Commit 规范

commit 信息需要简要描述改动的内容。
commit 摘要的长度不要超过 45 字。如果需要，请在正文中详细说明。

commit 摘要，推荐按照下面的格式编辑：

<修改类型>(<文件名>): <修改的内容>

修改类型有这几种：

feat：添加内容

fix：修正内容错误

refactor：对一个页面进行重构（较大规模的更改）

revert：回退更改

Pull Request 规范

标题写明 PR 的目的（做了什么工作）。内容请简要叙述修改的内容。

如果修复了一个 issue 的问题，请在内容中添加 sovle #xxxx 字段，其中 xxxx 代表 issue 的编号。

标题推荐使用如下格式书写：

<修改类型>(<文件名>): <修改的内容> (<对应 issue 的编号>)

修改类型有这几种：

feat：添加内容

fix：修正内容错误

refactor：对一个页面进行重构（较大规模的更改）

revert：回退更改

阅读友好

考虑读者感受。偏僻别名不应该出现。要使用标准术语，规范。如果需要新增术语，请添加说明，如果是比较复杂的术语，请增加到术语表中。

拒绝短设问

取消一些不必要的短问答形式

比如

问题
短回答

应该改成如果 xxx，读 xxx

格式化

不要对内容格式化，合并时审视内容改动很困难。

需要的话，请专门提一个请求进行格式优化。

排序，重要章节放在前面

越高频，重要的信息应该越靠前。

负责

如果内容只有链接，请做简述或提取主要内容。请不要丢这样的简短内容。

### 增加的内容

[内容链接]()

### 下一个内容

提交内容

先确保您的内容符合 GitHub 条款，在你的更改被合并到主仓库之前，你所作出的改动均不会出现在页面上，可以放心编辑。

通知进度

在开始编写一段内容之前，请查阅 Issues，确认没有冲突的工作（如果有，可以在 Issue 下交流），然后创建一个新 issue 记录待编写的内容。

Tip

编辑时请关闭网页翻译插件。

编辑单个页面

你可以直接点击正文右上方编辑按钮。

在编辑框内编写你想修改的内容，编写完成后滚动到页面下方，按照本文中 commit 规范填写 commit 信息，之后点击绿色按钮提交修改。点击按钮后，GitHub 会自动帮你克隆一份仓库的分支然后跳转到仓库页面。

点击页面上方绿色的 Create pull request 按钮，跳转到创建 Pull Request 页面。再次检查自己所作出的修改，按照本文中 Pull Request 提交规范一节中的规范书写提交信息，然后点 Create pull request 按钮创建合并请求。

喝一杯热茶！只需要等待审计，协作者会在审计完成后将它合并到主仓库中。

编辑多个页面

进入代码仓库页面，点击 Fork 克隆本仓库。

在你的仓库页面，点击键盘上的 . 按钮，进入 GitHub Dev 编辑器。

修改完成后使用左侧的 Source Control 选项卡（像 V 一样的图标），并按照本文中 commit 规范提交。

然后点击分支选项卡（像 n 一样的图标），创建拉取请求，INTO 设置为主仓库地址。在下面的编辑框按照格式填写标题和描述，然后点击 Create 按钮创建请求。（如果你是未完成分支，请勾选 Create as draft ）。

追加更改只需要在原有分支再次编辑即可，会自动追加到请求中。

增加索引

在 mkdocs.yml 中添加纲目和对应大标题的翻译。

扩展阅读

开源指南

写作参考

https://www.cnblogs.com/xiaozhi_5638/p/15847859.html#b4
https://segmentfault.com/a/1190000011858100?utm_source=sf-similar-article