Created Code of conduct (markdown)

Code-of-conduct.md

@@ -0,0 +1,34 @@
+不同分支、不同属性、不同目标下的开发遵循不同的贡献规范，以工程友好度为准。
+
+# Branches
+
+## master
+主分支，项目的默认开发跟踪分支。
+
+### commit
+主分支上的每个提交（commit）都应该可以通过编译，这是基本规范，也是对此分支其他开发流程规范的基本约束。
+
+### Pull Request
+你总是应该通过 Pull Request 流程来向 `master` 分支提交代码。提交时 merge 方式的选择有以下两种，分情况进行：
+
+- `squash merge` 在 `commit` 多且杂，且不好对 `commit` 进行细分时使用；或者是以模块为单位的 breaking change ，并且仅当整个模块被包含进来（这个PR中的一部分commit必须在一起）时才能通过编译时，请采用此方式。
+
+- `rebase merge` 在 `commit` 信息规范，每个 `commit` 的原子性、功能性都良好时，可以直接进行 `rebase merge`，以方便对不同位置的错误进行单元性的追踪与修正。
+
+## feature/xxx
+特性分支，包含模块性的、需要多人协作开发的功能单元。
+
+### commit
+特性分支的 commit 规范没有强要求，取决于分支维护者。但在这里，我们可以给出几点参考性实践指南，帮助大家遵守基本的分支贡献规范：
+
+- 代码格式化：当你向分支提交代码时，请使用 `cargo fmt` 对你的代码进行格式化。这对其他人的眼睛及阅读体验友好。
+
+- 可过编译性：commit 作为单元应该有意义，所以 commit 大部分情况下总是应该保证可以过编译，至少可以过静态分析。
+
+- 合作性：公共的特性分支，作为方便开发跟踪与多人协作的分支，你应该注意你的代码在提交时不会导致其他人的开发被过度打扰。有几点可以帮助你做到这一点：
+
+  - 不要将细碎的、与提交无关的格式、修补，与你的主要修改内容合在同一个 commit 提交，尤其是那些不在你的开发范围内的修改。开发范围的隔离，是较好的防止代码冲突的方法。
+
+  - 将你的修补内容以语义为单位分割，而不是功能。譬如说，你可能对一系列 C 风格的代码进行了抽象来重构，但是有时候一时半会儿不能实现原来的功能。这不重要，进行良好的风格重构本身语义上就具有意义。当可以过编译时，将现有的修改直接作为一个 commit 提交也是一个好的选择，后续的功能补丁再通过后续的 commit 完成。这样，可以让他人及时获悉你对接口的基本修改，及时为后续其他方面的开发变更对应的接口抽象。
+
+  - 及时在 issue 中反映你开发时遇到的问题，并千万结合你的代码提交。由于代码提交到公共特性分支，他人进行 checkout 检查及及时进行修正的效率会大大提高，整个开发周期最终的以缩短。结合代码提交请通过 GitHub Code Permalink 粘贴，这样可以方便他人跟踪代码变更的上下文。