如何参与一个 GitHub 开源项目？（转）

转自：http://mp.weixin.qq.com/s?__biz=MjM5MzA0ODkyMA==&mid=200909764&idx=1&sn=5184c6637977a94916508379b194f3e0

2014-04-14 @realzp
developerWorks



【说明】本文原载于码农IO（manong.io）官方微信
developerWorks，转载、引用请注明出处及作者。

原文地址：https://guides.github.com/overviews/os-contributing/

本文译者：@realzp

参与开源项目最好的方式就是为这些项目作出你的贡献。现在 GitHub 上已经有 500 多万个开源项目，这些项目涵盖了诸如 recipes, HTML/CSS, Ruby, Astrophysics 等等的各种技术。这篇文章会告诉你在面对这些项目时需要知道的内容以及如何作出你的贡献。

找到项目

我们建议你从一些你已经在使用的项目开始寻找，以下是几个推荐的地方：

GitHub Explore, https://github.com/explore
GitHub Stars, https://github.com/stars?direction=desc&sort=created
GitHub Showcases, https://github.com/showcases
LayerVault News, http://news.layervault.com/


一个典型的项目

以下是你在 GitHub 上的开源项目中很可能遇到的一些知识点：

社区

项目通常会有个社区，由不同角色的（正式或非正式）用户组成：

Owner - 所有者，是创建该项目的用户或者组织，拥有该项目。

Maintainers and Collaborators - 维护者和协作者，是把握项目方向和作出主要修改的用户。一般来说所有者和维护者是相同的。他们有这些项目代码库的写入权限。

Contributors - 贡献者，每一个对该项目作出过 pull request 并最终代码合并入项目的用户。

Community Members - 社区成员，经常使用并深切关注项目，积极参与项目功能和 pull request 讨论的用户。

文档

项目中经常遇到的文档：

Readme

几乎所有的 Github 项目都包含了一个 README.md 文件，readme 介绍了项目的基本情况：是什么、如何使用/编译、甚至于如何为项目作出共享。

Contributing

各个项目是不同的，各个项目维护者也不一样，所以对项目作出共享的方式也是各有千秋。请你时刻关注标签为 CONTRIBUTING 的文档，那里面描述了项目拥有者所希望加入的补丁或者功能，这些可能包含写哪些测试、代码风格或者补丁需要注意的地方。

License

标签为 LICENSE 的文档是项目的许可文件。开源项目的许可文档规定了用户可以做和不可以做的事情（例如：使用、修改、分发），也包括了贡献者所规定的允许其他人所做的事情。目前有很多种许可能被用在开源项目上，你可以从这里找到更多关于各种许可的信息：http://choosealicense.com/

Documentation and Wikis

很多大型的项目使用比 readme 文件更丰富的方式来介绍项目的使用说明，这种情况下你通常可以找到一个指向代码库中 docs 文件/文件夹的链接。



另一种方式就是使用 GitHub wiki 来存放代码库的文档。



对项目作出贡献

好了，你已经了解了项目，是时候开始行动了！



创建一个问题

如果你找到了项目的一个 Bug （也不知道如何修复它）、阅读项目文档的时候遇到了困难，或者对项目有疑问 - 去创建一个问题！这没什么大不了的，不管你遇到什么样的问题，大多数情况下是不会只有你一个人遇到的，所以总会有人也能从你的问题中得到帮助。想知道更多关于问题的信息请访问：http://guides.github.com/overviews/issues

问题进阶提示

确认你的问题是否已经在已有问题中 - 重复的问题会降低各方的效率，所以在你提出问题前，请搜索已有的问题（包括已解决和未解决的），确保你的问题没有被提出过。

清楚地表达你的问题 - 什么是期望的输出？什么是实际情况？如何重现该问题？

例子链接 - 可以通过例子重现问题，就像：http://jsfiddle.net/ 或者 http://codepen.io/
介绍你的系统环境 - 哪种浏览器或者运行库？操作系统的类型以及版本？

放上错误的输出日志 - 你可以使用 http://gist.github.com/ 或者直接把输出和日志贴在问题上。记得在前后都加上 ```，那样就能显示更优雅。

Pull Request

如果你可以自己修复 bug 或者增加功能，太好了，对代码创建一个 pull request！不过在这之前请确保你已经读过相关的文档，了解了许可，如果需要的话，同意一些协议。一旦你提交了一个 pull request ，那么维护者就可以比较你的分支并决定是否包含 (pull in) 你的修改。

Pull Request 进阶提示

Fork 代码库并做本地克隆。把项目本身的代码库作为远端库加入到你的本地项目。时不时地更新远端库的代码，这样你就能跟项目的实际进度保持一致，减少了以后提交代码时需要的冲突解决。如果需要这方面更详细的信息，请访问：https://help.github.com/articles/syncing-a-fork

为你的修改创建分支。

请十分明确你要修改的问题和重现方式，或者是增加的功能，然后同样地明确你准备如何去修改或者实现。

最好是测试过的 - 对于你的修改运行现有的测试（如果测试存在），如有必要则创建新的测试。无论是否有现成的测试，请确保你的修改不会对已有的项目产生负面影响。

包含截屏 - 如果你的修改是关于 HTML/CSS 的，请包含修改前和修改后的截屏。直接将图片拖入 pull request 中即可。

尽力保证项目的已有代码风格 - 这意味着你也许需要使用和你的习惯所不相同的代码缩进、分号，或者是注释方式，但这会让项目的维护者更容易地使用你的代码，风格一致性也方便了其他人阅读理解代码。

开放 Pull Request

一旦你开放了一个 pull request，就会围绕你提议的这个修改产生讨论。其他贡献者和用户也许会有各种不同的意见，但最后的决定权还是在维护者那。你可能会被要求对你 pull request 做一些修改，如果那样的话，只需对你的分支做需要的修改提交，这些修改会自动进入现有的 pull request。



如果你的 pull request 被合并了，那太好了！如果没被合并，也没什么大不了的，可能这不是项目维护者期望看到的改动，也可能他们正在处理。这种情况时有发生，所以我们建议：对收到的结果作出反馈，进一步尝试并且再次 pull request - 或者直接创建你自己的开源项目。

（全文完）

【说明】本文原载于码农IO（manong.io）官方微信
developerWorks，转载、引用请注明出处及作者。

----

码农IO（manong.io），专注于IT技术干货分享。

新浪微博：@developerWorks

微信号：developerWorks