Github作為開源項(xiàng)目的著名托管地，可謂無(wú)人不知，越來(lái)越多的個(gè)人和公司紛紛加入到Github的大家族里來(lái)，為開源盡一份綿薄之力。對(duì)于個(gè)人來(lái)講，你把自己的項(xiàng)目托管到Github上并不表示你參與了Github開源項(xiàng)目，只能說(shuō)你開源了自己的項(xiàng)目，可以任別人自由下載。那么該如何參與Github的開源項(xiàng)目呢？為此，Github官方團(tuán)隊(duì)曾經(jīng)寫了一篇很棒的文章 Contributing to Open Source on GitHub，專業(yè)指導(dǎo)大家如何參與Github的開源項(xiàng)目。 下面是原文及翻譯。

---

原文路徑：https://guides.github.com/activities/contributing-to-open-source/

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各個(gè)領(lǐng)域 like?recipes,?HTML/CSS,?Ruby,?Astrophysics?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:

• GitHub Explore: Popular and trending熱門 projects.
• GitHub Stars: Projects starred by other people.
• GitHub Showcases: A way to discover related repositories.相關(guān)庫(kù)
• Designer News: Front-end development and design projects.

A Typical Project

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

The Community社區(qū)

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維護(hù)者 and Collaborators協(xié)作者?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權(quán)限?to the repository.
• Contributors貢獻(xiàn)者?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細(xì)節(jié) 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標(biāo)注?CONTRIBUTING. Contributing docs detail the specifics about how a project’s maintainer would like to see patches補(bǔ)丁 or features功能 contributed. This can include what tests to write, code syntax語(yǔ)法 style or areas to focus on for patches.

License許可

A?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重新發(fā)布), 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指導(dǎo) 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很簡(jiǎn)單 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專業(yè)提示

• Check existing issues?for your issue. Duplicating重復(fù) 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呈現(xiàn) nicely.

Pull Request

If you’re able to patch修復(fù) 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遠(yuǎn)程.?Pull in changes?from ‘upstream’ often經(jīng)常 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出現(xiàn) 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縮進(jìn), semi colons分號(hào) or comments注釋 differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain維護(hù) 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沒(méi)什么大不了的, 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繼續(xù)努力 and pull request again – or create your own open source project.

---

參與開源項(xiàng)目的最佳辦法就是加入到你正在使用的已有項(xiàng)目上來(lái)。Github上有500多萬(wàn)開源項(xiàng)目，涉及到各個(gè)領(lǐng)域的技術(shù)，像 recipes, HTML/CSS, Ruby, Astrophysics等等。該指南將涵蓋你在一個(gè)典型的項(xiàng)目中可能出現(xiàn)的事情以及如何為開源項(xiàng)目作出貢獻(xiàn)。找項(xiàng)目我們推薦你從已正在使用的或感興趣的項(xiàng)目開始。這里有幾個(gè)很棒的地方供你參考：GitHub Explore：受歡迎和熱門的項(xiàng)目。 GitHub Stars：被其他人star過(guò)的項(xiàng)目（指的是你自己庫(kù)的項(xiàng)目）。 GitHub Showcases：一個(gè)能搜索相關(guān)庫(kù)的方法。 LayerVault News：前端和設(shè)計(jì)相關(guān)的項(xiàng)目。 一個(gè)典型的項(xiàng)目下面是一些你在Github開源項(xiàng)目中可能遇到的因素。The Community（社區(qū)）項(xiàng)目通常會(huì)有一個(gè)社區(qū)維護(hù)，由不同角色（正規(guī)或非正規(guī)）的其他用戶組成：所有者（Owner）：即創(chuàng)建該項(xiàng)目且在他們Github賬戶上有該項(xiàng)目的用戶或組織。 維護(hù)者和協(xié)作者（Maintainers and Collaborators）： 致力于一個(gè)項(xiàng)目并促進(jìn)該項(xiàng)目發(fā)展的用戶。通常所有者和維護(hù)者是同一個(gè)用戶或組織，他們對(duì)項(xiàng)目庫(kù)都有寫的權(quán)限。 貢獻(xiàn)者（Contributors）：每一個(gè)對(duì)該項(xiàng)目發(fā)出過(guò)pull request并合并到項(xiàng)目中的用戶都是貢獻(xiàn)者。 社區(qū)成員（Community Members）：即那些經(jīng)常使用且非常關(guān)心該項(xiàng)目的用戶，他們?cè)谟懻摴δ芴卣骱蚿ull request上非?；钴S。The Docs（文檔）一般項(xiàng)目中都有的文件。Readme：幾乎所有的Github項(xiàng)目都包含一個(gè)README.md文件。readme提供了該項(xiàng)目的一個(gè)概覽及關(guān)于如何使用、構(gòu)建甚至如何貢獻(xiàn)于一個(gè)項(xiàng)目的相關(guān)細(xì)節(jié)。Contributing：項(xiàng)目和項(xiàng)目維護(hù)者不同，所以每個(gè)項(xiàng)目所期望的作貢獻(xiàn)的最佳方法也會(huì)有所不同。一定要注意一個(gè)標(biāo)注為CONTRIBUTING的文檔，Contributing文檔詳細(xì)描述了一個(gè)項(xiàng)目的維護(hù)者希望看到貢獻(xiàn)的補(bǔ)丁或功能應(yīng)該符合怎樣的規(guī)格。這可能包含要寫什么測(cè)試，代碼語(yǔ)法規(guī)范或補(bǔ)丁集中的區(qū)域。License：一個(gè)LICENSE文件當(dāng)然就是該項(xiàng)目的許可證了。一個(gè)開源項(xiàng)目的license會(huì)告訴用戶他們能做和不能做的（例如使用、修改、重新發(fā)布），及告訴貢獻(xiàn)者他們?cè)试S其他人做的。有許多的辦法對(duì)開源項(xiàng)目加上許可證，你可以在 choosealicense.com讀到更多的關(guān)于每個(gè)許可證的含義。Documentation and Wikis：許多大型項(xiàng)目有的不只有一個(gè)readme來(lái)指導(dǎo)人么如何使用他們的項(xiàng)目。在這種情況下你通常能夠發(fā)現(xiàn)一個(gè)指向庫(kù)中名為“docs”的另一個(gè)文件或文件夾的鏈接。另外，該庫(kù)也可能使用Github wiki來(lái)代替文檔。 貢獻(xiàn)于一個(gè)項(xiàng)目既然你已經(jīng)找到了理解該項(xiàng)目的相關(guān)資料，下面你就可以采取一些行動(dòng)了。建立一個(gè)話題如果你發(fā)現(xiàn)了你正在使用的項(xiàng)目中的一個(gè)bug（但是你不知道怎么去修復(fù)它），或?qū)ξ臋n有不解或?qū)?xiàng)目有疑問(wèn) — 那么創(chuàng)建一個(gè)話題吧！這非常容易且一般你不管創(chuàng)建什么話題，你都可能不是唯一一個(gè)出現(xiàn)該問(wèn)題的人，所以其他人可能會(huì)發(fā)現(xiàn)你的話題很有幫助。關(guān)于更多的話題介紹，請(qǐng)查看我們的 Issues guide。話題專業(yè)提示在建話題之前檢查已有的話題：話題重復(fù)對(duì)雙方都無(wú)利，所以搜索整個(gè)正開放和已關(guān)閉的話題以檢查你遇到的問(wèn)題是否已經(jīng)有人解決了。 務(wù)必對(duì)自己的問(wèn)題有清晰的認(rèn)識(shí)：期望的結(jié)果是什么？然而卻發(fā)生了什么？ 詳細(xì)描述其他人如何重現(xiàn)該問(wèn)題。在像 JSFiddle或 CodePen類似的平臺(tái)上重現(xiàn)該問(wèn)題并給出問(wèn)題demo的鏈接。 包含一些系統(tǒng)相關(guān)的細(xì)節(jié)，比如用的什么瀏覽器、庫(kù)或操作系統(tǒng)及版本號(hào)。 在你的話題或在 Gist里貼出你的錯(cuò)誤輸出或日志。如果在話題里貼出來(lái)，請(qǐng)用三個(gè)反引號(hào)``` 包圍起來(lái)使得能夠良好的呈現(xiàn)給大家。Pull Request如果你能夠修復(fù)bug或自己添加功能 — 太棒了，請(qǐng)發(fā)一個(gè)pull request吧！確保你已經(jīng)讀過(guò)任何關(guān)于contributing的文檔，且需要理解license以及已經(jīng)簽過(guò)CLA（如果需要的話）。一旦你提交了一個(gè)pull request，維護(hù)者就會(huì)將你的分支與已有的分支作比較來(lái)決定是否要合并（即pull in）你作的改動(dòng)。Pull Request專業(yè)提示Fork 該項(xiàng)目庫(kù)及將它c(diǎn)lone到本地。通過(guò)添加為遠(yuǎn)程的方式在本地連接到原來(lái)的‘upstream’庫(kù)。經(jīng)常從‘upstream’庫(kù)pull in改動(dòng)以保持庫(kù)最新，這樣當(dāng)你提交pull request時(shí)，就不大可能發(fā)生合并沖突了。點(diǎn) 這里看更多的指導(dǎo)細(xì)節(jié)。 為你的編輯單獨(dú)建立一個(gè)分支 。務(wù)必清楚所出現(xiàn)的問(wèn)題以及如何重現(xiàn)該問(wèn)題或?yàn)槭裁茨愕墓δ苡袔椭?。然后同樣的要清楚做一些改變有哪些步驟。 最好測(cè)試一下。在任何已有的測(cè)試（如果存在）上運(yùn)行你所做的改動(dòng)并在必要時(shí)創(chuàng)建新的測(cè)試。不管測(cè)試存不存在，都要確保你的改動(dòng)不會(huì)破壞已有的項(xiàng)目。 如果你的改動(dòng)包含了HTML/CSS方面的不同，那么請(qǐng)包含改動(dòng)前和改動(dòng)后的截圖。將你的圖片拖放到你pull request的正文里。 盡你所能的在項(xiàng)目的風(fēng)格上多做努力。這可能意味著使用不同于你自己Github庫(kù)中采用的縮進(jìn)，分號(hào)或注釋，但是這讓維護(hù)者更容易合并，也讓其他人更容易理解和以后的維護(hù)。開放的Pull Requests一旦你打開一個(gè)pull request，就會(huì)有一個(gè)討論，圍繞你提出的改變作出探討。其他的貢獻(xiàn)者和用戶可能會(huì)參與進(jìn)來(lái)，但最終由維護(hù)者做決定。你可能會(huì)被要求對(duì)你的pull request做一些改變，如果這樣，請(qǐng)給你的分支添加更多的commit并push它們 — 它們將自動(dòng)的加入到已有的pull request里。如果你的pull request被合并了——太好了！如果沒(méi)被合并的話，也沒(méi)什么大不了的，也許這不是項(xiàng)目維護(hù)者所期望看到的改動(dòng)，亦或者他們已經(jīng)致力于該bug或功能。這種情況有可能發(fā)生，所以我們的建議是：對(duì)收到的結(jié)果做出反饋，進(jìn)一步努力然后再次pull request出去— 或者創(chuàng)建你自己的開源項(xiàng)目。

來(lái)自為知筆記(Wiz)

轉(zhuǎn)載于:https://www.cnblogs.com/baiqiantao/p/fe712a833842ddf9b84d324b84dfc5d3.html

總結(jié)

以上是生活随笔為你收集整理的如何参与一个GitHub开源项目的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。