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

最近一年开源项目特别的热，不少技术大会或论坛都以开源项目做为主题进行探讨，可见这是一种趋势。而Github做为开源项目的著名托管地，可谓无 人不知，愈来愈多的我的和公司纷纷加入到Github的你们族里来，为开源尽一份绵薄之力。对于我的来说，你把本身的项目托管到Github上并不表示你 参与了Github开源项目，只能说你开源了本身的项目，能够任别人自由下载。

那么该如何参与Github的开源项目呢？相信不少人都有这方面的疑问，网 上也有一些良莠不齐的教程教你们如何“pull request”、如何“commit”等等。但这些教程每每不够全面或不够彻底正确，搞很差可能让你陷 入一个误区。鉴于此，前几天Github官方团队写了一篇很棒的文章Contributing to Open Source on GitHub，专业指导你们如何参与Github的开源项目。做为Github的入门级粉丝，将这篇教程翻译出来，供那些对开源项目刚兴趣的人参考借鉴。

参与开源项目的最佳办法就是加入到你正在使用的已有项目上来。Github上有500多万开源项目，涉及到各个领域的技术，像recipes,HTML/CSS,Ruby, Astrophysics等等。该指南将涵盖你在一个典型的项目中可能出现的事情以及如何为开源项目做出贡献。

找项目

咱们推荐你从已正在使用的或感兴趣的项目开始。这里有几个很棒的地方供你参考：

• GitHub Explore:  受欢迎和热门的项目。

• GitHub Stars:  被其余人star过的项目（指的是你本身库的项目）。

• GitHub Showcases:  一个能搜索相关库的方法。

• LayerVault News:  .前端和设计相关的项目。

 

一个典型的项目

下面是一些你在Github开源项目中可能遇到的因素。

The Community（社区）

项目一般会有一个社区维护，由不一样角色（正规或非正规）的其余用户组成：

• 全部者（Owner）：即建立该项目且在他们Github帐户上有该项目的用户或组织。

• 维护者和协做者（Maintainers and Collaborators）： 致力于一个项目并促进该项目发展的用户。一般全部者和维护者是同一个用户或组织，他们对项目库都有写的权限。

• 贡献者（Contributors）：每个对该项目发出过pull request并合并到项目中的用户都是贡献者。

• 社区成员（Community Members）：即那些常用且很是关心该项目的用户，他们在讨论功能特征和pull request上很是活跃。

The Docs（文档）

通常项目中都有的文件。

Readme

几乎全部的Github项目都包含一个README.md 文件。readme提供了该项目的一个概览及关于如何使用、构建甚至如何贡献于一个项目的相关细节。

Contributing

项目和项目维护者不一样，因此每一个项目所指望的做贡献的最佳方法也会有所不一样。必定要注意一个标注为CONTRIBUTING的文档，Contributing文档详细描述了一个项目的维护者但愿看到贡献的补丁或功能应该符合怎样的规格。这可能包含要写什么测试，代码语法规范或补丁集中的区域。

License

一个LICENSE文件固然就是该项目的许可证了。一个开源项目的license会告诉用户他们能作和不能作的（例如使用、修改、从新发布），及告诉贡献者他们容许其余人作的。有许多的办法对开源项目加上许可证，你能够在choosealicense.com读到更多的关于每一个许可证的含义。

Documentation and Wikis

许多大型项目有的不仅有一个readme来指导人么如何使用他们的项目。在这种状况下你一般可以发现一个指向库中名为“docs”的另外一个文件或文件夹的连接。

 

另外，该库也可能使用Github wiki来代替文档。

 

贡献于一个项目

既然你已经找到了理解该项目的相关资料，下面你就能够采起一些行动了。

创建一个话题

若是你发现了你正在使用的项目中的一个bug（可是你不知道怎么去修复它），或对文档有不解或对项目有疑问 — 那么建立一个话题吧！这很是容易且通常你无论建立什么话题，你均可能不是惟一一个出现该问题的人，因此其余人可能会发现你的话题颇有帮助。

话题专业提示

• 在建话题以前检查已有的话题：话题重复对双方都无利，因此搜索整个正开放和已关闭的话题以检查你遇到的问题是否已经有人解决了。

• 务必对本身的问题有清晰的认识：指望的结果是什么？然而却发生了什么？ 详细描述其余人如何重现该问题。

• 在像JSFiddle 或CodePen相似的平台上重现该问题并给出问题demo的连接。

• 包含一些系统相关的细节，好比用的什么浏览器、库或操做系统及版本号。

• 在你的话题或在Gist里贴出你的错误输出或日志。若是在话题里贴出来，请用三个反引号``` 包围起来使得可以良好的呈现给你们。

Pull Request

若是你可以修复bug或本身添加功能 — 太棒了，请发一个pull request 吧！确保你已经读过任何关于contributing的文档，且须要理解license以及已经签过CLA（若是须要的话）。一旦你提交了一个 pull request，维护者就会将你的分支与已有的分支做比较来决定是否要合并（即pull in）你做的改动。

Pull Request专业提示

• Fork 该项目库及将它clone到本地。经过添加为远程的方式在本地链接到原来的‘upstream’库。常常从‘upstream’库pull in改动以保持库最新，这样当你提交pull request时，就不大可能发生合并冲突了。

• 为你的编辑单独创建一个分支 。

• 务必清楚所出现的问题以及如何重现该问题或为何你的功能有帮助。而后一样的要清楚作一些改变有哪些步骤。

• 最好测试一下。在任何已有的测试（若是存在）上运行你所作的改动并在必要时建立新的测试。无论测试存不存在，都要确保你的改动不会破坏已有的项目。

• 若是你的改动包含了HTML/CSS方面的不一样，那么请包含改动前和改动后的截图。将你的图片拖放到你pull request的正文里。

• 尽你所能的在项目的风格上多作努力。这可能意味着使用不一样于你本身Github库中采用的缩进，分号或注释，可是这让维护者更容易合并，也让其余人更容易理解和之后的维护。

开放的Pull Requests

一旦你打开一个pull request，就会有一个讨论，围绕你提出的改变做出探讨。其余的贡献者和用户可能会参与进来，但最终由维护者作决定。你可能 会被要求对你的pull request作一些改变，若是这样，请给你的分支添加更多的commit并push它们 — 它们将自动的加入到已有的pull request里。

 

若是你的pull request被合并了 — 太好了！若是没被合并的话，也没什么大不了的，也许这不是项目维护者所指望看到的改动，亦或者他们已经致力于该bug或功能。这种状况有可能发生，所 以咱们的建议是：对收到的结果作出反馈，进一步努力而后再次pull request出去— 或者建立你本身的开源项目。