最近一年開源項目特別的熱，很多技術大會或論壇都以開源項目作為主題進行探討，可見這是一種趨勢。而Github作為開源項目的著名托管地，可謂無 人不知，越來越多的個人和公司紛紛加入到Github的大家族里來，為開源盡一份綿薄之力。對於個人來講，你把自己的項目托管到Github上並不表示你 參與了Github開源項目，只能說你開源了自己的項目，可以任別人自由下載。那么該如何參與Github的開源項目呢？相信很多人都有這方面的疑問，網 上也有一些參差不齊的教程教大家如何“pull request”、如何“commit”等等。但這些教程往往不夠全面或不夠完全正確，搞不好可能讓你陷 入一個誤區。鑒於此，前幾天Github官方團隊寫了一篇很棒的文章Contributing to Open Source on GitHub，專業指導大家如何參與Github的開源項目。作為Github的入門級粉絲，將這篇教程翻譯出來，供那些對開源項目剛興趣的人參考借鑒。
下面是正文。我的Github地址：https://github.com/lanxuezaipiao，有自己的項目也有fork的非常優秀的編程資料、編程筆記和計算機優秀論文資料，有興趣的可以follow下。
參與開源項目的最佳辦法就是加入到你正在使用的已有項目上來。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
Contributing
項目和項目維護者不同，所以每個項目所期望的作貢獻的最佳方法也會有所不同。一定要注意一個標注為CONTRIBUTING
License
一個LICENSE
Documentation and Wikis
許多大型項目有的不只有一個readme來指導人么如何使用他們的項目。在這種情況下你通常能夠發現一個指向庫中名為“docs”的另一個文件或文件夾的鏈接。
另外，該庫也可能使用Github wiki來代替文檔。
貢獻於一個項目
既然你已經找到了理解該項目的相關資料，下面你就可以采取一些行動了。
建立一個話題
如果你發現了你正在使用的項目中的一個bug（但是你不知道怎么去修復它），或對文檔有不解或對項目有疑問 — 那么創建一個話題吧！這非常容易且一般你不管創建什么話題，你都可能不是唯一一個出現該問題的人，所以其他人可能會發現你的話題很有幫助。關於更多的 話題介紹，請查看我們的Issues guide。
話題專業提示
- 在建話題之前檢查已有的話題：話題重復對雙方都無利，所以搜索整個正開放和已關閉的話題以檢查你遇到的問題是否已經有人解決了。
- 務必對自己的問題有清晰的認識：期望的結果是什么？然而卻發生了什么？ 詳細描述其他人如何重現該問題。
- 在像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出去— 或者創建你自己的開源項目。
如果你跟我一樣是開源的支持者，請點擊下面的推薦按鈕 (*^__^*)