最近一年開源專案特別的熱，很多技術大會或論壇都以開源專案作為主題進行探討，可見這是一種趨勢。而Github作為開源專案的著名託管地，可謂無 人不知，越來越多的個人和公司紛紛加入到Github的大家族裡來，為開源盡一份綿薄之力。對於個人來講，你把自己的專案託管到Github上並不表示你 參與了Github開源專案，只能說你開源了自己的專案，可以任別人自由下載。那麼該如何參與Github的開源專案呢？相信很多人都有這方面的疑問，網 上也有一些參差不齊的教程教大家如何“pull request”、如何“commit”等等。但這些教程往往不夠全面或不夠完全正確，搞不好可能讓你陷 入一個誤區。鑑於此，前幾天Github官方團隊寫了一篇很棒的文章

下面是正文。我的Github地址：https://github.com/lanxuezaipiao，有自己的專案也有fork的非常優秀的程式設計資料、程式設計筆記和計算機優秀論文資料，有興趣的可以follow下。

參與開源專案的最佳辦法就是加入到你正在使用的已有專案上來。Github上有500多萬開源專案，涉及到各個領域的技術，像recipes,HTML/CSS,Ruby, Astrophysics

找專案

我們推薦你從已正在使用的或感興趣的專案開始。這裡有幾個很棒的地方供你參考：

一個典型的專案

下面是一些你在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（但是你不知道怎麼去修復它），或對文件有不解或對專案有疑問 — 那麼建立一個話題吧！這非常容易且一般你不管建立什麼話題，你都可能不是唯一一個出現該問題的人，所以其他人可能會發現你的話題很有幫助。關於更多的 話題介紹，請檢視我們的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出去— 或者建立你自己的開源專案。

如果你跟我一樣是開源的支持者，請點選下面的推薦按鈕 (*^__^*)