怎样在Github参与一个开源项目
轉載：http://www.csdn.net/article/2014-04-14/2819293-Contributing-to-Open-Source-on-GitHub
?
最近一年開源項目特別的熱，很多技術大會或論壇都以開源項目作為主題進行探討，可見這是一種趨勢。而Github作為開源項目的著名托管地，可謂無人不知，越來越多的個人和公司紛紛加入到Github的大家族里來，為開源盡一份綿薄之力。對于個人來講，你把自己的項目托管到Github上并不表示你參與了Github開源項目，只能說你開源了自己的項目，可以任別人自由下載。
那么該如何參與Github的開源項目呢？相信很多人都有這方面的疑問，網上也有一些參差不齊的教程教大家如何“Pull Request”、如何“Commit”等等。但這些教程往往不夠全面或不夠完全正確，搞不好可能讓你陷入一個誤區。鑒于此，前幾天Github官方團隊寫了一篇很棒的文章?Contributing to Open Source on 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（但是你不知道怎么去修復它），或對文檔有不解或對項目有疑問 —?那么創建一個話題吧！這非常容易且一般你不管創建什么話題，你都可能不是唯一一個出現該問題的人，所以其他人可能會發現你的話題很有幫助。關于更多的話題介紹，請查看我們的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出去—?或者創建你自己的開源項目。
總結
以上是生活随笔為你收集整理的怎样在Github参与一个开源项目的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【编程题目】求二叉树中节点的最大距离
- 下一篇： 实验一HSRP与STP结合