-
Notifications
You must be signed in to change notification settings - Fork 1.5k
贡献代码
王玉鹏 edited this page Jul 3, 2017
·
2 revisions
首先我们非常感谢您的贡献,正是有您的努力,RePlugin才会越来越优秀! 您可以贡献代码去修复一些bug,添加新的特性,或者重构某些代码,使得代码更加美观易于维护。 在这里,我们给出RePlugin的贡献代码流程机制,以让您能够更好地贡献代码。
RePlugin的贡献基本流程如下图:
下面就上图的代码贡献流程做出以下说明:
- 首先登录GitHub,将RePlugin工程 Fork 到你的个人名下
以下均是GitHub官方标准做法,详细可参见GitHub官方文档。
- 通过git clone将刚刚Fork到你个人名下的RePlugin项目同步到本地,并创建一个分支
- 所有的修改都在这个分支上进行
- 修改完毕之后将你的修改提交到本地,然后Push到你的Github远端仓库。
注意:分支命名方式
为了更好的地管理RePlugin的代码修改历史,我们接受的分支命名方式为:issueid_一个简短但是有意义的名字,例如:1234_support_taskaffinity。
这么做的目的是,很清晰地看出你的分支是做什么用的,而不会出现“通过提交记录和代码来找到提交内容”的情况。
- 请不要在你的提交记录中写上任何和issue id相关的信息,比如:fix issue 1234。因为我们的issue最终是会关闭的,如果你这里写上一个issue 1234的话,一段时间之后谁也不知道这里的fix issue 1234究竟修复了什么问题。
- 基于你的修改分支创建一个Pull Request
- 如果你的Pull Request被merge了,请及时更新相关的wiki或者文档,以及时展示你的修改。
- 所有的文件必须添加Apache 2 License开头
- 请不要在代码注释中使用@author,git会追踪你的信息
- 所有的function,class,interface,aidl都应该有一个良好的JavaDoc,以描述这段代码如何使用,有什么特性,有限什么局限。对于某些比较复杂的部分,可以在注释中写上一段使用的示例代码。
- git commit信息(要求必须英文且首句第一个单词的第一个字母要大写)应该是清晰的、明了的、可追踪的,并且还应该将修复同一个问题的若干git提交归纳在一起。大致来说,一个优雅的提交应该像这样:
Short (50 chars or fewer) summary of changes
More detailed explanatory text, if necessary. Wrap it to
72 characters. In some contexts, the first
line is treated as the subject of an email and the rest of
the text as the body. The blank line separating the
summary from the body is critical (unless you omit the body
entirely); tools like rebase can get confused if you run
the two together.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Use a hyphen or an asterisk for the bullet,
followed by a single space, with blank lines in
between
Source http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
更多详细信息请看git style。