如何參與一個 GitHub 開源項目？

最近一年開源項目特別的熱，不少技術大會或論壇都以開源項目做爲主題進行探討，可見這是一種趨勢。而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 文件。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出去— 或者建立你本身的開源項目。

若是你跟我同樣是開源的支持者，請點擊下面的推薦按鈕 (*^__^*) 

 

翻譯自：Contributing to Open Source on GitHub