mirror of
https://github.com/faas-rs/faasd-in-rust.git
synced 2025-06-09 08:16:47 +00:00
Created Code of conduct (markdown)
parent
ba7f46c5aa
commit
76f539b679
34
Code-of-conduct.md
Normal file
34
Code-of-conduct.md
Normal file
@ -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 粘贴,这样可以方便他人跟踪代码变更的上下文。
|
Loading…
x
Reference in New Issue
Block a user