如何參與一個GitHub開源項目


Github作為開源項目的著名托管地,可謂無人不知,越來越多的個人和公司紛紛加入到Github的大家族里來,為開源盡一份綿薄之力。對於個人來講, 你把自己的項目托管到Github上並不表示你參與了Github開源項目,只能說你開源了自己的項目,可以任別人自由下載。
那么該如何參與Github的開源項目呢?為此,Github官方團隊曾經寫了一篇很棒的文章 Contributing to Open Source on GitHub,專業指導大家如何參與Github的開源項目。 下面是原文及翻譯。





A great way to get involved in參與 open source is to contribute to the existing projects you’re using. GitHub is home to more than 5 million open source projects. There are projects for every skill set各個領域 like recipesHTML/CSSRubyAstrophysics and many more. This guide will cover涵蓋 what you might find in a typical project and how to make a great contribution.

Find Projects

We recommend推薦 that you start by finding a project that you’re already (or are interested in) using. Here are a few great places to look:

A Typical Project

Below are some elements you’re likely to come across遇到 in an open source project on GitHub.

The Community社區

Projects often have a community around them, made up of組成 other users in different (formal or informal) roles:

  • Owner is the user or organization that created the project has the project on their account.
  • Maintainers維護者 and Collaborators協作者 are the users primarily doing the work on a project and driving the direction駕駛方向. Oftentimes the owner and the maintainer are the same. They have write access權限 to the repository.
  • Contributors貢獻者 is everyone who has had a pull request merged合並 into a project.
  • Community Members are the users who often use and care deeply about the project and are active活躍 in discussions for features and pull requests.

The Docs

The what’s-what of common files in projects.

Readme

Nearly all GitHub projects include a README.md file. The readme provides a lay of the land for a project with details細節 on how to use, build and sometimes contribute to a project.

Contributing

Projects and project maintainers vary不同, so the best way to contribute will also vary. Keep your eye open for a doc labeled標注 CONTRIBUTING. Contributing docs detail the specifics about how a project’s maintainer would like to see patches補丁 or features功能 contributed. This can include what tests to write, code syntax語法 style or areas to focus on for patches.

License許可

LICENSE file, well, is the license for the project. An open source project’s license informs users what they can and can’t do (e.g., use, modify, redistribute重新發布), and contributors, what they are allowing others to do. There are many ways to license and open source project, you can read more about what each license means at choosealicense.com.

Documentation and Wikis

Many larger projects go beyond不止 a readme to give instructions指導 for how people can use their project. In such cases you’ll often find a link to another file or a folder named ‘docs’ in the repository.

Alternatively另外, the repository may instead代替 use the GitHub wiki to break down documentation.

Contributing to a Project

Now that you’ve found the material資料 for understanding the project, here is how you can take action.

Create an Issue話題

If you find a bug in a project you’re using (and you don’t know how to fix it), have trouble following the documentation or have a question about the project – create an issue! There’s nothing to it很簡單 and whatever issue you’re having, you’re likely not the only one, so others will find your issue helpful, too. For more information on how issues work, check out our Issues guide.

Issues Pro Tips專業提示

  • Check existing issues for your issue. Duplicating重復 an issue is slower for both parties so search through open and closed issues to see if what you’re running into has been addressed解決 already.
  • Be clear about what your problem is: what was the expected outcome, what happened instead? Detail how someone else can recreate the problem.
  • Link鏈接 to demos recreating the problem on things like JSFiddle or CodePen.
  • Include system details like what the browser, library or operating system you’re using and its version.
  • Paste error output or logs in your issue or in a Gist. If pasting them in the issue, wrap包裹 it in three backticks: ` ``` ` so that it renders呈現 nicely.

Pull Request

If you’re able to patch修復 the bug or add the feature yourself – fantastic太棒了, make a pull request with the code! Be sure you’ve read any documents on contributing, understand the license and have signed a Contributor Licence Agreement (CLA) if required. Once you’ve submitted提交 a pull request the maintainer(s) can compare比較 your branch to the existing one and decide whether or not to incorporate合並 (pull in) your changes.

Pull Request Pro Tips

  • Fork the repository and clone it locally. Connect your local to the original原始的 ‘upstream’ repository by adding it as a remote遠程. Pull in changes from ‘upstream’ often經常 so that you stay up保持 to date so that when you submit your pull request, merge conflicts合並沖突 will be less likely. See more detailed instructions here.
  • Create a branch for your edits.
  • Be clear about what problem is occurring出現 and how someone can recreate that problem or why your feature will help. Then be equally同樣 as clear about the steps步驟 you took to make your changes.
  • It’s best to test. Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don’t break破壞 the existing project.
  • Include screenshots of the before and after if your changes include differences in HTML/CSS. Drag and drop拖放 the images into the body of your pull request.
  • Contribute in the style of the project to the best of your abilities盡你所能. This may mean using indents縮進, semi colons分號 or comments注釋 differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain維護 in the future.

Open Pull Requests

Once you’ve opened a pull request, a discussion will start, around your proposed changes. Other contributors and users may chime in參與, but ultimately最終 the decision is made by the maintainer(s). You may be asked to make some changes to your pull request, if so, add more commits to your branch and push them – they’ll automatically go into the existing pull request.

If your pull request is merged – great! If it is not, no sweat沒什么大不了的, it may not be what the project maintainer had in mind所期望的, or they were already working on it. This happens, so our recommendation建議 is to take any feedback you’ve received and go forth繼續努力 and pull request again – or create your own open source project.



參與開源項目的最佳辦法就是加入到你正在使用的已有項目上來。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出去— 或者創建你自己的開源項目。





免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM