Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
机器未来
Paddle
提交
8983caad
P
Paddle
项目概览
机器未来
/
Paddle
与 Fork 源项目一致
Fork自
PaddlePaddle / Paddle
通知
1
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
1
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
P
Paddle
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
1
Issue
1
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
提交
8983caad
编写于
5月 15, 2017
作者:
T
Tao Luo
提交者:
GitHub
5月 15, 2017
浏览文件
操作
浏览文件
下载
差异文件
Merge pull request #2139 from luotao1/contribute_doc
add appointments for contributing codes in document
上级
2e527ad3
bade3e97
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
20 addition
and
0 deletion
+20
-0
doc/howto/dev/contribute_to_paddle_cn.md
doc/howto/dev/contribute_to_paddle_cn.md
+20
-0
未找到文件。
doc/howto/dev/contribute_to_paddle_cn.md
浏览文件 @
8983caad
...
...
@@ -7,6 +7,7 @@
-
确保编译器选项
`WITH_STYLE_CHECK`
已打开,并且编译能通过代码样式检查。
-
所有代码必须具有单元测试。
-
通过所有单元测试。
-
请遵守
[
提交代码的一些约定
](
#提交代码的一些约定
)
。
以下教程将指导您提交代码。
## [Fork](https://help.github.com/articles/fork-a-repo/)
...
...
@@ -217,3 +218,22 @@ upstream
```
至此,我们就完成了一次代码贡献的过程。
## 提交代码的一些约定
为了使评审人在评审代码时更好地专注于代码本身,请您每次提交代码时,遵守以下约定:
1.
请保证Travis-CI 中单元测试能顺利通过。如果没过,说明提交的代码存在问题,评审人一般不做评审。
2.
提交PUll Request前:
-
请注意commit的数量:
-
原因:如果仅仅修改一个文件但提交了十几个commit,每个commit只做了少量的修改,这会给评审人带来很大困扰。评审人需要逐一查看每个commit才能知道做了哪些修改,且不排除commit之间的修改存在相互覆盖的情况。
-
建议:每次提交时,保持尽量少的commit,可以通过
`git commit --amend`
补充上次的commit。对已经Push到远程仓库的多个commit,可以参考
[
squash commits after push
](
http://stackoverflow.com/questions/5667884/how-to-squash-commits-in-git-after-they-have-been-pushed
)
。
-
请注意每个commit的名称:应能反映当前commit的内容,不能太随意。
3.
如果解决了某个Issue的问题,请在该PUll Request的
**第一个**
评论框中加上:
`fix #issue_number`
,这样当该PUll Request被合并后,会自动关闭对应的Issue。关键词包括:close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved,请选择合适的词汇。详细可参考
[
Closing issues via commit messages
](
https://help.github.com/articles/closing-issues-via-commit-messages
)
。
此外,在回复评审人意见时,请您遵守以下约定:
1.
评审人的每个意见都必须回复(这是开源社区的基本礼貌,别人帮了忙,应该说谢谢):
-
对评审意见同意且按其修改完的,给个简单的
`Done`
即可;
-
对评审意见不同意的,请给出您自己的反驳理由。
2.
如果评审意见比较多:
-
请给出总体的修改情况。
-
请采用
[
start a review
](
https://help.github.com/articles/reviewing-proposed-changes-in-a-pull-request/
)
进行回复,而非直接回复的方式。原因是每个回复都会发送一封邮件,会造成邮件灾难。
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录