Code of conduct

不同分支、不同属性、不同目标下的开发遵循不同的贡献规范，以工程友好度为准。

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 粘贴，这样可以方便他人跟踪代码变更的上下文。

Pull Request

分支代码贡献不要求使用 pull request 流程。但是，当分支更改内容繁杂时，使用 pr 流程未必不是个好的选择。

Issues

• 尽量说人话，给清楚前因后果、代码上下文，说清楚你想实现的效果 or 遇到的（有问题的）现象

• 也可以将正在开发的内容 or 打算开发的内容列出

• issue 总是应该尽快跟 branch 或 pull request 关联。没有关联的孤儿 issue 会让事务 loss control