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