[Feature-215][docs] add developer documentation

5277697c · wenmo · 87ebc55b · 5277697c · 5277697c · 5277697c
Commit 5277697c authored Mar 22, 2022 by wenmo
7 changed files
--- a/docs/zh-CN/_sidebar.md
+++ b/docs/zh-CN/_sidebar.md
@@ -9,10 +9,9 @@
 - 入门
  - [编译](/zh-CN/quick_start/build.md)
  - [部署](/zh-CN/quick_start/deploy.md)
- 基本使用指南
+- 使用手册
- 参考手册
  - FlinkSQL Studio
-    - [Studio介绍](/zh-CN/administrator-guide/Studio/studio_introduce.md) 
+    - [Studio介绍](/zh-CN/administrator-guide/Studio/studio_introduce.md)
    - 作业管理
    - 作业开发
    - 作业配置
@@ -33,34 +32,37 @@
    - 作业监控
  - openapi
 - 扩展
-  - 集成
+  - 功能扩展
-  - 其他
    - [扩展Flink版本](/zh-CN/extend/flinkversion.md)
    - [扩展连接器](/zh-CN/extend/connector.md)
    - [扩展数据源](/zh-CN/extend/datasource.md)
    - [FlinkSQL 编辑器自动补全函数](/zh-CN/extend/completion.md)
- 最佳实践
+  - 集成生态
-  - [Yarn提交实践指南](/zh-CN/practice/yarnsubmit.md)
-  - [Dlink 核心概念及实现原理详解](/zh-CN/practice/principle.md)
-  - [AGGTABLE 表值聚合的实践](/zh-CN/practice/aggtable.md)
-  - 集成指南
    - [Flink-CDC集成](/zh-CN/extend/flinkcdc.md)
    - [Flink-CDC-Kafka多源合并](/zh-CN/extend/Flink_CDC_kafka_Multi_source_merger.md)
    - [hive集成](/zh-CN/extend/hive.md)
-    - [clickhouse集成](/zh-CN/extend/clickhouse.md) 
+    - [clickhouse集成](/zh-CN/extend/clickhouse.md)
-    - [Doris集成](/zh-CN/extend/doris.md) 
+    - [Doris集成](/zh-CN/extend/doris.md)
    - [Hudi集成](/zh-CN/extend/hudi.md)
    - [Iceberg集成](/zh-CN/extend/iceberg.md)
    - [Flink UDF集成](/zh-CN/extend/udf.md)
    - [DolphinScheduler集成](/zh-CN/extend/dolphinscheduler.md)
    - [DataSphereStudio集成](/zh-CN/extend/dataspherestudio.md)
+- 实践分享
+  - [Yarn提交实践指南](/zh-CN/practice/yarnsubmit.md)
+  - [Dlink 核心概念及实现原理详解](/zh-CN/practice/principle.md)
+  - [AGGTABLE 表值聚合的实践](/zh-CN/practice/aggtable.md)
 - 开发者指南
-  - [参与贡献](/zh-CN/developer-guide/how_contribute.md)
+  - 参与贡献
+    - [如何贡献](/zh-CN/developer-guide/how_contribute.md)
+    - [文档贡献](/zh-CN/developer-guide/document.md)
+    - [Issue 须知](/zh-CN/developer-guide/issue.md)
+    - [Pull Request 须知](/zh-CN/developer-guide/pull_request.md)
+    - [Commit Message 须知](/zh-CN/developer-guide/commit_message.md)
+    - [提交代码须知](/zh-CN/developer-guide/commit_code.md)
  - [本地调试](/zh-CN/developer-guide/local_debug.md)
  - [远程调试](/zh-CN/developer-guide/remote_debug.md)
 - [常见问题](/zh-CN/FAQ.md)
 - [致谢](/zh-CN/others/thanks.md)
 - [交流与贡献](/zh-CN/others/comminicate.md)
 - [roadmap](/zh-CN/roadmap.md)
\ No newline at end of file
--- a/docs/zh-CN/developer-guide/commit_code.md
+++ b/docs/zh-CN/developer-guide/commit_code.md
+# 提交代码
+* 首先从远端仓库 *https://github.com/DataLinkDC/dlink.git*  fork一份代码到自己的仓库中
+* 远端仓库中目前有三个分支：
+    * master 正常交付分支
+      发布稳定版本以后，将稳定版本分支的代码合并到 master 上。
+    * dev 日常开发分支
+      日常 dev 开发分支，新提交的代码都可以 pull request 到这个分支上。
+    * 0.6.0 发布版本分支
+      发布版本分支，后续会有 1.0... 等版本分支。
+* 把自己仓库 clone 到本地
+  ```sh
+  git clone https://github.com/DataLinkDC/dlink.git
+  ```
+* 添加远端仓库地址，命名为 upstream
+  ```sh
+  git remote add upstream https://github.com/DataLinkDC/dlink.git
+  ```
+* 查看仓库
+  ```sh
+  git remote -v
+  ```
+> 此时会有两个仓库：origin（自己的仓库）和 upstream（远端仓库）
+* 获取/更新远端仓库代码（已经是最新代码，就跳过）
+  ```sh
+  git fetch upstream
+  ```
+* 同步远端仓库代码到本地仓库
+  ```sh
+   git checkout origin/dev
+   git merge --no-ff upstream/dev
+  ```
+如果远端分支有新加的分支比如`dev-1.0`,需要同步这个分支到本地仓库
+  ```sh
+  git checkout -b dev-1.0 upstream/dev-1.0
+  git push --set-upstream origin dev-1.0
+  ```
+* 新建分支
+  ```sh
+  git checkout -b xxx origin/dev
+  ```
+确保分支 `xxx` 是基于官方 dev 分支的最新代码
+* 在新建的分支上本地修改代码以后，提交到自己仓库：
+  ```sh
+  git commit -m 'commit content'
+  git push origin xxx --set-upstream
+  ```
+* 将修改提交到远端仓库
+    * 在 github 的 Pull Request 页面，点击 "New pull request"
+    * 选择修改完的本地分支和要合并的目的分支，点击 "Create pull request"
+* 接着社区 Committer 们会做 CodeReview，然后他会与您讨论一些细节（包括设计，实现，性能等）。当团队中所有人员对本次修改满意后，会将提交合并到 dev 分支
+* 最后，恭喜您已经成为了 Dinky 的官方贡献者！
\ No newline at end of file
--- a/docs/zh-CN/developer-guide/commit_message.md
+++ b/docs/zh-CN/developer-guide/commit_message.md
+一个好的 commit message 是能够帮助其他的开发者（或者未来的开发者）快速理解相关变更的上下文，同时也可以帮助项目管理人员确定该提交是否适合包含在发行版中。但当我们在查看了很多开源项目的 commit log 后，发现一个有趣的问题，一部分开发者，代码质量很不错，但是 commit message 记录却比较混乱，当其他贡献者或者学习者在查看代码的时候，并不能通过 commit log 很直观的了解
+该提交前后变更的目的，正如 Peter Hutterer 所言：Re-establishing the context of a piece of code is wasteful. We can’t avoid it completely, so our efforts should go to reducing it as much as possible. Commit messages can do exactly that and as a result, a commit message shows whether a developer is a good collaborator. 因此，DolphinScheduler 结合其他社区以及 Apache 官方文档制定了该规约。
+### Commit Message RIP
+#### 1：明确修改内容
+commit message 应该明确说明该提交解决了哪些问题（bug 修复、功能增强等），以便于用户开发者更好的跟踪问题，明确版本迭代过程中的优化情况。
+#### 2：关联相应的Pull Request 或者Issue
+当我们的改动较大的时候，commit message 最好能够关联 GitHub 上的相关 Issue 或者 Pull Request，这样，我们的开发者在查阅代码的时候能够通过关联信息较为迅速的了解改代码提交的上下文情景，如果当前 commit 针对某个 issue，那么可以在 Footer 部分关闭这个 issue。
+#### 3：统一的格式
+格式化后的 CommitMessage 能够帮助我们提供更多的历史信息，方便快速浏览，同时也可以直接从 commit 生成 Change Log。
+Commit message 应该包括三个部分：Header，Body 和 Footer。其中，Header 是必需的，Body 和 Footer 可以省略。
+##### header
+Header 部分只有一行，包括三个字段：type（必需）、scope（可选）和 subject（必需）。
+[ISSUE编号][type] subject
+(1) type 用于说明 commit 的类别，只允许使用下面7个标识。
+* feat：新功能（feature）
+* fix：修补bug
+* docs：文档（documentation）
+* style： 格式（不影响代码运行的变动）
+* refactor：重构（即不是新增功能，也不是修改bug的代码变动）
+* test：增加测试
+* chore：构建过程或辅助工具的变动
+如果 type 为 feat 和 fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）建议不放入。
+(2）scope
+scope 用于说明 commit 影响的范围，比如 admin、alert 等，如果没有更合适的范围，你可以用 *。
+(3) subject
+subject 是 commit 目的的简短描述，不超过50个字符。
+##### Body
+Body 部分是对本次 commit 的详细描述，可以分成多行，换行符将以72个字符换行，避免自动换行影响美观。
+Body 部分需要注意以下几点：
+* 使用动宾结构，注意使用现在时，比如使用 change 而非 changed 或 changes
+* 首字母不要大写
+* 语句最后不需要 ‘.’ (句号) 结尾
+##### Footer
+Footer只适用于两种情况
+(1) 不兼容变动
+如果当前代码与上一个版本不兼容，则 Footer 部分以 BREAKING CHANGE 开头，后面是对变动的描述、以及变动理由和迁移方法。
+(2) 关闭 Issue
+如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue,也可以一次关闭多个 issue 。
+##### 举个例子
+[DS-001][docs-zh] add commit message
+* commit message RIP
+* build some conventions
+* help the commit messages become clean and tidy
+* help developers and release managers better track issues
+  and clarify the optimization in the version iteration
+This closes #001
+### 参考文档
+[提交消息格式](https://cwiki.apache.org/confluence/display/GEODE/Commit+Message+Format)
+[On commit messages-Peter Hutterer](http://who-t.blogspot.com/2009/12/on-commit-messages.html)
+[RocketMQ Community Operation Conventions](https://mp.weixin.qq.com/s/LKM4IXAY-7dKhTzGu5-oug)
\ No newline at end of file
--- a/docs/zh-CN/developer-guide/document.md
+++ b/docs/zh-CN/developer-guide/document.md
+良好的使用文档对任何类型的软件都是至关重要的。欢迎任何可以改进 Dinky 文档的贡献。
+### 获取文档项目
+Dinky 项目的文档维护在源码 docs 目录中。
+首先你需要先将源项目 fork 到自己的 github 仓库中，然后将 fork 的文档克隆到本地计算机中。
+```shell
+git clone https://github.com/<your-github-user-name>/dlink
+```
+### 文档环境
+Dinky 网站由 [docsify](https://docsify.js.org/#/zh-cn/quickstart) 提供支持。
+请确保你已经安装了 nodejs 和 npm 。详细安装步骤可以查阅本地调试。
+### 文档构建
+在 Dinky 的根目录下执行：
+```shell
+# 推荐全局安装 docsify-cli 工具
+npm i docsify-cli -g
+# 运行 docsify serve 启动一个本地服务器
+docsify serve docs
+```
+可以方便地实时预览效果。默认访问地址 [http://localhost:3000](http://localhost:3000/)
+### 文档规范
+汉字与英文、数字之间需空格，中文标点符号与英文、数字之间不需空格，以增强中英文混排的美观性和可读性。
+建议在一般情况下使用 “你” 即可。当然必要的时候可以使用 “您” 来称呼，比如有 warning 提示的时候。
+### 怎样提交文档 Pull Request
+不要使用“git add.”提交所有更改。只需推送更改的文件，例如：*.md。
+向 dev 分支提交 Pull Request。
+### 参考文档
+更多规范请参考 [Apache Flink 中文文档规范](https://cwiki.apache.org/confluence/display/FLINK/Flink+Translation+Specifications)
\ No newline at end of file
--- a/docs/zh-CN/developer-guide/how_contribute.md
+++ b/docs/zh-CN/developer-guide/how_contribute.md
@@ -26,22 +26,13 @@
 ## 参与文档贡献
-首先要下载 [Dinky源码](https://github.com/DataLinkDC/dlink/tree/dev) ，下载完成后，需要安装nodejs和npm。详细安装步骤可以查阅本地调试。由于Dinky文档是有 [docsify](https://docsify.js.org/#/zh-cn/quickstart) 维护。因此需要在dinky根目录执行如下命令，在本地方可启动：
+请查阅 [文档贡献](/zh-CN/developer-guide/document.md)
-```shell
-# 推荐全局安装 docsify-cli 工具
-npm i docsify-cli -g
-# 运行 docsify serve 启动一个本地服务器
-docsify serve docs
-```
-可以方便地实时预览效果。默认访问地址 [http://localhost:3000](http://localhost:3000/)
 ## 参与代码贡献
-调试请查阅 [本地调试](/zh-CN/developer-guide/local_debug.md) 或 [远程调试](/zh-CN/developer-guide/remote_debug.md)
+IDEA 调试请查阅 [本地调试](/zh-CN/developer-guide/local_debug.md) 及 [远程调试](/zh-CN/developer-guide/remote_debug.md)
-贡献参考[参与贡献 Issue 需知]()，[参与贡献 Pull Request 需知]()，[参与贡献 CommitMessage 需知]()
+贡献请查阅 [Issue 需知](/zh-CN/developer-guide/issue.md)，[Pull Request 需知](/zh-CN/developer-guide/pull_request.md)，[Commit Message 需知](/zh-CN/developer-guide/commit_message.md)
 ## 如何领取 Issue，提交 Pull Request
@@ -49,8 +40,8 @@ docsify serve docs
 - 所有的 Bug 与新 Feature 建议使用 Issues Page 进行管理。
 - 如果想要开发实现某个 Feature 功能，请先回复该功能所关联的 Issue，表明你当前正在这个 Issue 上工作。 并在回复的时候为自己设置一个最后期限，并添加到回复内容中。
- 你应该新建一个分支来开始你的工作，分支的名字参考[参与贡献 Pull Request 需知]()。比如，你想完成 feature 功能并提交了 Issue demo，那么你的 branch 名字应为 feature-demo。 功能名称可与导师讨论后确定。
+- 你应该新建一个分支来开始你的工作，分支的名字参考 [Pull Request 需知](/zh-CN/developer-guide/pull_request.md)。比如，你想完成 feature 功能并提交了 Issue demo，那么你的 branch 名字应为 feature-demo。 功能名称可与导师讨论后确定。
- 完成后，发送一个 Pull Request 到 Dinky 的 dev 分支，提交过程具体请参考下面《[提交代码流程]()》。
+- 完成后，发送一个 Pull Request 到 Dinky 的 dev 分支，提交过程具体请参考下面《[提交代码须知](/zh-CN/developer-guide/commit_code.md)》。
 如果是想提交 Pull Request 完成某一个 Feature 或者修复某个 Bug，这里都建议大家从小处做起，完成一个小功能就提交一次，每次别改动太多文件，改动文件太多也会给 Reviewer 造成很大的心理压力，建议通过多次 Pull Request 的方式完成。

--- a/docs/zh-CN/developer-guide/issue.md
+++ b/docs/zh-CN/developer-guide/issue.md
+Issues 功能被用来追踪各种特性，Bug，功能等。项目维护者可以通过 Issues 来组织需要完成的任务。
+Issue 是引出一个 Feature 或 Bug 等的重要步骤，在单个 Issue 中可以讨论的内容包括但不限于 Feature 的包含的功能，存在的 Bug 产生原因，前期方案的调研，以及其对应的实现设计和代码思路。
+并且只有当 Issue 被 approve 之后才需要有对应的 Pull Request 去实现。
+如果是一个 Issue 对应的是一个大 Feature，建议先将其按照功能模块等维度分成多个小的 Issue。
+### Issue 标题
+标题格式：[`Issue 类型`][`模块名`] `Issue 描述`
+其中`Issue 类型`如下：
+<table>
+    <thead>
+        <tr>
+            <th style="width: 10%; text-align: center;">Issue 类型</th>
+            <th style="width: 20%; text-align: center;">描述</th>
+            <th style="width: 20%; text-align: center;">样例</th>
+        </tr>
+    </thead>
+    <tbody>
+        <tr>
+            <td style="text-align: center;">Feature</td>
+            <td style="text-align: center;">包含所期望的新功能和新特性</td>
+            <td style="text-align: center;">[Feature][admin] Add xxx admin in xxx controller</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">Bug</td>
+            <td style="text-align: center;">程序中存在的 Bug</td>
+            <td style="text-align: center;">[Bug][admin] Throw exception when xxx</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">Improvement</td>
+            <td style="text-align: center;">针对目前程序的一些改进，不限于代码格式，程序性能等</td>
+            <td style="text-align: center;">[Improvement][executor] Improve xxx on executor</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">Test</td>
+            <td style="text-align: center;">专门针对测试用例部分</td>
+            <td style="text-align: center;">[Test][metadata-mysql] Add xxx metadata-mysql test</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">Sub-Task</td>
+            <td style="text-align: center;">一般都是属于 Feature 类的子任务，针对大 Feature，可以将其分成很多个小的子任务来一一完成</td>
+            <td style="text-align: center;">[Sub-Task][executor] Implement xxx in xxx</td>
+        </tr>
+    </tbody>
+</table>
+其中`模块名`如下：
+<table>
+    <thead>
+        <tr>
+            <th style="width: 10%; text-align: center;">模块名</th>
+            <th style="width: 20%; text-align: center;">描述</th>
+        </tr>
+    </thead>
+    <tbody>
+        <tr>
+            <td style="text-align: center;">admin</td>
+            <td style="text-align: center;">管理模块</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">alert</td>
+            <td style="text-align: center;">报警模块</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">app</td>
+            <td style="text-align: center;">Flink APP 模块</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">assembly</td>
+            <td style="text-align: center;">打包模块</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">client</td>
+            <td style="text-align: center;">Flink Client 模块</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">common</td>
+            <td style="text-align: center;">基础模块</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">connectors</td>
+            <td style="text-align: center;">Flink Connector 模块</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">core</td>
+            <td style="text-align: center;">核心模块</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">daemon</td>
+            <td style="text-align: center;">守护线程模块</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">doc</td>
+            <td style="text-align: center;">资源模块</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">docs</td>
+            <td style="text-align: center;">官网文档</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">executor</td>
+            <td style="text-align: center;">执行器模块</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">extends</td>
+            <td style="text-align: center;">扩展模块</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">function</td>
+            <td style="text-align: center;">Flink UDF 模块</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">gateway</td>
+            <td style="text-align: center;">提交网关模块</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">metadata</td>
+            <td style="text-align: center;">元数据模块</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">web</td>
+            <td style="text-align: center;">Web 模块</td>
+        </tr>
+    </tbody>
+</table>
+### Issue 内容模板
+[Issue 模板](https://github.com/DataLinkDC/dlink/tree/dev/.github/ISSUE_TEMPLATE)
+### Bug 类 Issue
+当您发现一个 Bug 时，请提交一个 Issue 类的 Bug，提交前：
+* 请先在 issue 列表里查找一下是否该 Bug 已经提交，如果已经有此 Bug，请在此 Bug 下接着回复。
+* 如果该 Bug 是可以复现的。请尽量提供完整的重现步骤。
+请在 Issues 页面中提交 Bug。
+一个高质量的 Bug 通常有以下特征：
+* 使用一个清晰并有描述性的标题来定义 Bug。
+* 详细的描述复现 Bug 的步骤。包括您的配置情况，预计产生的结果，实际产生的结果。并附加详细的 TRACE 日志。
+* 如果程序抛出异常，请附加完整的堆栈日志。
+* 如有可能，请附上屏幕截图或动态的 GIF 图，这些图片能帮助演示整个问题的产生过程。
+* 哪个版本。
+* 需要修复的优先级(危急、重大、次要、细微)。
+下面是 **Bug 的 Markdown 内容模板**，请按照该模板填写 issue。
+```shell
+**标题** 
+标题格式: [BUG][Priority] bug标题
+Priority分为四级: Critical、Major、Minor、Trivial
+**问题描述**
+[清晰准确描述遇到的问题]
+**问题复现步骤:**
+1. [第一步]
+2. [第二步]
+3. [...]
+**期望的表现:**
+[在这里描述期望的表现]
+**观察到的表现:**
+[在这里描述观察到的表现]
+**屏幕截图和动态GIF图**
+![复现步骤的屏幕截图和动态GIF图](图片的url)
+**Dinky 版本:(以0.6.0为例)** 
+ -[0.6.0]
+**补充的内容:**
+[请描述补充的内容，比如]
+**需求或者建议**
+[请描述你的需求或者建议]
+```
+### Feature 类 Issue
+提交前：
+* 请确定这不是一个重复的功能增强建议。 查看 Issue Page 列表，搜索您要提交的功能增强建议是否已经被提交过。
+请在 issues 页面中提交 Feature。
+一个高质量的 Feature 通常有以下特征：
+* 一个清晰的标题来定义 Feature
+* 详细描述 Feature 的行为模式
+* 说明为什么该 Feature 对大多数用户是有用的。新功能应该具有广泛的适用性。
+* 尽量列出其他平台已经具备的类似功能。商用与开源软件均可。
+以下是 **Feature 的 Markdown 内容模板**，请按照该模板填写 issue 内容。
+```shell
+**标题** 
+标题格式: [Feature][Priority] feature标题
+Priority分为四级: Critical、Major、Minor、Trivial
+**Feature的描述**
+[描述新Feature应实现的功能]
+**为什么这个新功能是对大多数用户有用的**
+[解释这个功能为什么对大多数用户是有用的]
+**补充的内容**
+[列出其他的调度是否包含该功能，是如何实现的]
+```
+### Contributor
+除一些特殊情况之外，在开始完成 Issue 之前，建议先在 Issue 下或者邮件列表中和大家讨论确定设计方案或者提供设计方案，以及代码实现思路。
+如果存在多种不同的方案，建议通过邮件列表或者在 Issue 下进行投票决定，最终方案和代码实现思路被 approve 之后，再去实现，这样做的主要目的是避免在
+Pull Request review 阶段针对实现思路的意见不同或需要重构而导致 waste time。
+### 相关问题
+- 当出现提出 Issue 的用户不清楚该 Issue 对应的模块时的处理方式。
+  确实存在大多数提出 Issue 用户不清楚这个 Issue 是属于哪个模块的，其实这在很多开源社区都是很常见的。在这种情况下，其实 committer/contributor 是知道这个 Issue 影响的模块的，如果之后这个 Issue 被 committer 和 contributor approve 确实有价值，那么 committer 就可以按照 Issue 涉及到的具体的模块去修改 Issue 标题，或者留言给提出 Issue 的用户去修改成对应的标题。
\ No newline at end of file
--- a/docs/zh-CN/developer-guide/pull_request.md
+++ b/docs/zh-CN/developer-guide/pull_request.md
+Pull Request 本质上是一种软件的合作方式，是将涉及不同功能的代码，纳入主干的一种流程。这个过程中，可以进行讨论、审核和修改代码。
+在 Pull Request 中尽量不讨论代码的实现方案，代码及其逻辑的大体实现方案应该尽量在 Issue 或者邮件列表中被讨论确定，在 Pull Request 中我们尽量只关注代码的格式以及代码规范等信息，从而避免实现方式的意见不同而导致 waste time。
+### Pull Request 标题
+标题格式：[`Pull Request 类型`-`Issue 号`][`模块名`] `Pull Request 描述`
+其中`Pull Request 类型`和`Issue 类型`的对应关系如下：
+<table>
+    <thead>
+        <tr>
+            <th style="width: 10%; text-align: center;">Issue 类型</th>
+            <th style="width: 20%; text-align: center;">Pull Request 类型</th>
+            <th style="width: 20%; text-align: center;">样例（假设 Issue 号为 3333）</th>
+        </tr>
+    </thead>
+    <tbody>
+        <tr>
+            <td style="text-align: center;">Feature</td>
+            <td style="text-align: center;">Feature</td>
+            <td style="text-align: center;">[Feature-3333][admin] Implement xxx</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">Bug</td>
+            <td style="text-align: center;">Fix</td>
+            <td style="text-align: center;">[Fix-3333][admin] Fix xxx</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">Improvement</td>
+            <td style="text-align: center;">Improvement</td>
+            <td style="text-align: center;">[Improvement-3333][alert] Improve the performance of xxx</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">Test</td>
+            <td style="text-align: center;">Test</td>
+            <td style="text-align: center;">[Test-3333][metadata-mysql] Add the e2e test of xxx</td>
+        </tr>
+        <tr>
+            <td style="text-align: center;">Sub-Task</td>
+            <td style="text-align: center;">Sub-Task 对应的父类型</td>
+            <td style="text-align: center;">[Feature-3333][admin] Implement xxx</td>
+        </tr>
+    </tbody>
+</table>
+其中 `Issue 号`是指当前 Pull Request 对应要解决的 Issue 号，`模块名`同 Issue 的模块名。
+### Pull Request 分支名
+分支名格式：`Pull Request 类型`-`Issue 号`，举例：Feature-1。
+### Pull Request 内容
+请参阅到 commit message 篇。
+### Pull Request Code Style
+当你向 Dinky 提交 pull request 的时候 code-style 是你不得不考虑的问题。我们在 CI 中使用 Checkstyle [参考](https://checkstyle.sourceforge.io/)来保持代码风格的统一，它是一种帮助开发者编写遵循编码规范的 Java 代码开发工具。如果你的 pull request 没有通过 Checkstyle 的检测，那它将不会被合并到主库中。你可以在提交 pull request 前使用  Checkstyle 来检测或者格式化你的代码。如下的步骤将引领你配置并激活 Checkstyle
+1. 准备 Checkstyle 配置文件：你可以点击[这里](https://github.com/apache/dolphinscheduler/blob/dev/style/checkstyle.xml)手动下载，但是我们更加推荐在 Dinky 代码库中找到它。当你将代码库克隆下来后，你可以在路径 `style/checkstyle.xml` 下找到配置文件
+2. 下载 Intellij IDEA Checkstyle 插件：通过关键字**CheckStyle-IDEA**或者通过[这个页面](https://plugins.jetbrains.com/plugin/1065-checkstyle-idea)安装均可。如果你不清楚如何安装Intellij IDEA插件，可以参考[这个连接](https://www.jetbrains.com/help/idea/managing-plugins.html#install_plugin_from_repo)
+3. 配置并激活 Checkstyles 以及 Intellij IDEA 代码风格：当完成上面几步后，你就可以配置并激活他们了。你可以在路径`Preferences -> Tool -> Checkstyle`中找到 Checkstyle，请参照下图完成其配置
+<p align="center">
+    <img src="/img/checkstyle-idea.png" alt="checkstyle idea configuration" />
+</p>
+截止目前，Checkstyle 插件已经配置完成了，当有代码或者文件不符合风格时就会显示在 Checkstyle 中。但强烈建议同时配置 Intellij IDEA 的代码风格，完成配置后可以使用 Intellij IDEA 自动格式化功能。你可以在路径`Preferences -> Editor -> Code Style -> Java`找到配置，请参照下图完成其配置
+<p align="center">
+    <img src="/img/code-style-idea.png" alt="code style idea configuration" />
+</p>
+1. 在提交 pull request 前格式化你的代码：完成上面全部后，你可以使用快捷键`Command + L`(Mac用户) or `Ctrl+L`(Windows用户)在 Intellij IDEA 完成自动格式化。格式化代码的最佳时间是将你的修改提交到本地 git 版本库之前
+### 相关问题
+- 怎样处理一个 Pull Request 对应多个 Issue 的场景。
+  首先 Pull Request 和 Issue 一对多的场景是比较少的。Pull Request 和 Issue 一对多的根本原因就是出现了多个
+  Issue 需要做大体相同的一件事情的场景，通常针对这种场景有两种解决方法：第一种就是把多个功能相同的 Issue 合并到同一个 Issue 上，然后把其他的
+  Issue 进行关闭；第二种就是多个 Issue 大体上是在做一个功能，但是存在一些细微的差别，这类场景下可以把每个 Issue 的职责划分清楚，每一个
+  Issue 的类型都标记为 Sub-Task，然后将这些 Sub-Task 类型的 Issue 关联到一个总 Issue 上，在提交
+  Pull Request 时，每个 Pull Request 都只关联一个 Sub-Task 的 Issue。
+  尽量把一个 Pull Request 作为最小粒度。如果一个 Pull Request 只做一件事，Contributor 容易完成，Pull Request 影响的范围也会更加清晰，对 reviewer 的压力也会小。
\ No newline at end of file