It's been over 5 years since my post how to contribute a patch to an Open Source Project. That post is focused primarily on Subversion as the source control system. If you are using CodePlex and Subversion for example, those instructions work great. Here's the same idea for GitHub projects.
自从我发表文章以来，已经为开源项目贡献了补丁已有5年了。 该文章主要关注Subversion作为源代码控制系统。 例如，如果您使用的是CodePlex和Subversion，那么这些说明将非常有用。 这与GitHub项目的想法相同。
Folks email me all the time asking questions like "how can I be a better programmer?" "how do I get more experience?" or even the very specific "how can I make my resume more attractive?" My answer is almost always get involved in open source.
人们总是向我发送电子邮件，问诸如“我怎样才能成为一个更好的程序员？”之类的问题。 “我如何获得更多经验？” 甚至是非常具体的“如何使我的简历更具吸引力？” 我的回答几乎总是涉及开源。
Work with an open source project. Fix a bug, do their website, write some documentation. You don't necessarily even have to write code. A lot of open source projects need help and that help can mean doing forums work, support calls, whatever. The thing that folks forget about open source is that it's most volunteers who are doing it for the love of it. They show up.
使用一个开源项目。 修复错误，访问他们的网站，编写一些文档。 您甚至不必编写代码。 许多开源项目都需要帮助，而帮助可能意味着进行论坛工作，支持电话等等。 人们对开源的遗忘是，大多数志愿者是出于对开源的热爱而这么做的。 他们出现。
"80% of success is just showing up." - Woody Allen
“成功的80％刚刚出现。” - 伍迪·艾伦
Sometimes open source projects fail simply because only one or two people actually show up. Day after day. Using open source is easy, but making open source is hard.
有时开源项目失败只是因为实际上只有一两个人出现。 日复一日。 使用开源很容易，但是开源很困难。
NOTE: This example uses Git and GitHub. It is not meant to be comprehensive nor ideal. It is workable and works, but if you are considering working in Open Source or with Git for multiple projects and features you will want to explore more complete (and complex) workflows. There's an excellent "Git Workflow for Agile Teams" article, as well as a suggested Git Workflow from the NuGet team, and a fantastic screencast from Ryan Bates on contributing with Git as well as a fine screencasted introduction from Bobby Johnson.
注意：此示例使用Git和GitHub。 它并不意味着全面也不理想。 它是可行且可行的，但是如果您考虑在开源或Git中使用多个项目和功能，则需要探索更完整(更复杂)的工作流程。 有一篇出色的“敏捷团队的Git工作流程”一文，还有NuGet团队建议的Git工作流程，还有Ryan Bates撰写的有关Git贡献的精彩屏幕录像，以及Bobby Johnson的精彩屏幕录像介绍。
代码52 (Code 52)
It can be an overwhelming thing, though, to jump into a large open source project that is already established. It can also be hard to decide which small project to start, because no one wants to waste their time. How do you choose?
但是，跳入一个已经建立的大型开源项目可能是一件压倒性的事情。 由于没有人愿意浪费时间，因此很难决定要启动哪个小项目。 您如何选择？
Some lovely gents (Andrew Tobin, Brendan Forster and Paul Jenkins) over at Code 52 have started a great idea. A new coding project every week.
Code 52上一些可爱的绅士( Andrew Tobin ， Brendan Forster和Paul Jenkins )开始了一个好主意。 每周都有一个新的编码项目。
What a great idea! Nothing too hard that it can't be jumpstarted in a week. This totally lowers the barrier to entry and also encourages that things stay fresh. It also creates a bunch of great codebases for us (the community) to fork and spin off into larger projects that live longer than a week.
真是个好主意！ 没什么难的，一周之内就无法启动。 这完全降低了进入的障碍，也鼓励事物保持新鲜感。 它还为我们(社区)创建了一堆很棒的代码库，可以分拆并分解到寿命超过一周的大型项目中。
The guys says they figured a week because:
他们说他们花了一个星期是因为：
- shorter timelines encourage achievable goals. 较短的时间表鼓励实现目标。
- shorter timelines reduce the incentive to procrastinate. 较短的时间表减少了拖延的动机。
- more variety of projects to work on over a period of time. 在一段时间内会处理更多种类的项目。
为GitHub上的一个小型开源项目提供补丁 (Contributing a patch to a small Open Source project on GitHub)
The Code52 projects are hosted on GitHub. I host some of my own projects on BitBucket and others on CodePlex. It doesn't really matter where a project is as long as it makes you happy.
Code52项目托管在GitHub上。 我在BitBucket上托管我自己的一些项目，在CodePlex上托管其他项目。 项目在哪里并不重要，只要它能让您满意即可。
Let's say I want to contribute a fix to the DownmarkerWPF project they worked on a few weeks back. There's a few things I can do.
假设我想为他们几周前从事的DownmarkerWPF项目提供修复。 我有几件事可以做。
提出问题 (Raise an issue)
Filing a bug is literally the least you can do to help a project. Even better if it isn't a ragebug (where you just tell them how they suck) but includes everything you know about the issue, perhaps a stacktrace or a screenshot. Bonus points if you're kind in tone.
提交错误实际上是帮助项目的最少工作。 更好的是，如果它不是ragebug(您只是告诉他们它们的吮吸方式)，但包括有关该问题的所有信息，也许是stacktrace或屏幕截图。 如果您的语气友善，可加分。
建议功能 (Suggest a Feature)
Be helpful and suggest an interesting or innovative feature for their product. Bonus points if you include mockups, suggest a design or even better, start implementing it!
乐于助人，并为其产品提出有趣或创新的功能。 如果您包括模型，建议设计甚至更好的东西，就可以开始实施！
分叉代码，对其进行更改，然后执行“拉动请求” (Fork the Code, change it, then do a "pull request")
With some SCC (Source Control Systems) you'll change the code locally package it up as a "patch/diff" file and send that file onto the project team for integration at a later time. You'll want to just use the website for spelling changes and easy stuff.
使用某些SCC(源代码控制系统)，您将在本地更改代码，将其打包为“ patch / diff”文件，然后将该文件发送给项目团队以供以后集成。 您只需要使用该网站即可进行拼写更改和简单的操作。
With some newer systems like Mercurial and Git you'll push your code to a central place and send a "pull request" that says "hey, the code is over here, pull it in, m'kay?"
使用Mercurial和Git等一些较新的系统，您会将代码推送到中央位置，并发送一个“拉请求”，该消息说：“嘿，代码在这里，请拉进来，好吗？”
GitHub will allow you to make changes in the browser, but that's not realistic for actual code changes. Let's get the DownmarkerWPF code, change it, and submit a pull request.
GitHub允许您在浏览器中进行更改，但这对于实际的代码更改而言并不现实。 让我们获取DownmarkerWPF代码，对其进行更改，然后提交拉取请求。
It's a lovely Markdown Editor for Windows. If you don't want the source and just want a decent zipped up version you can run, you can download it.
这是Windows的一个可爱的Markdown编辑器。 如果您不想要源代码，而只想运行一个不错的压缩版本，则可以下载它。
Since I am going to fix what I think is an "issue" I'll first make an issue on the site and claim it. It's issue 82, so I will remember that number.
由于我要修复我认为是“问题”的内容，因此我将首先在网站上发布问题并提出声明。 第82期，所以我会记住那个数字。
I'll fork the code from the website and then clone my copy to my local machine. Note the URL I'm using is my fork of the code.
我将从网站上获取代码，然后将副本克隆到本地计算机上。 请注意，我使用的URL是我的代码分支。
C:\Code52>git clone https://shanselman@github.com/shanselman/DownmarkerWPF.
git
Cloning into DownmarkerWPF...
remote: Counting objects: 1870, done.
remote: Compressing objects: 100% (634/634), done.
remote: Total 1870 (delta 1347), reused 1728 (delta 1210)
Receiving objects: 100% (1870/1870), 11.40 MiB | 2.39 MiB/s, done.
Resolving deltas: 100% (1347/1347), done.
I could make a branch for myself to describe what I'm doing but I'm not going to because it's unnecessarily confusing for this example.
我可以为自己做一个分支来描述我在做什么，但我不会这样做，因为在这个示例中这不必要地造成混淆。
So, I love the idea of a Markdown editor for Windows as I'm writing a book with my wife using Markdown. However, my wife and I (and Leanpub.com) are using *.mkd as our extension, while the Code52 project uses *.md, *.markdown, and *.mdown. Here's an small but impactful change that I can make.
因此，当我与妻子使用Markdown编写一本书时，我喜欢Windows的Markdown编辑器的想法。 但是，我和我的妻子(和Leanpub.com )都使用* .mkd作为扩展名，而Code52项目则使用* .md，*。markdown和* .mdown。 这是我可以做的微小但有影响力的更改。
I'll find the code, and change it. Don't get overwhelmed now by the awesomeness and impact of this fix.
我将找到代码，然后进行更改。 现在不要被此修复程序的强大功能和影响所淹没。
public static class Constants
{
public static readonly string[] DefaultExtensions = new[] { ".md", ".markdown", ".mdown", ".mkd"};
...
}
Now I'll compile and test the change. It works!
现在，我将编译并测试更改。 有用！
Now I'll commit my change locally, then push it to the server. Add, Commit, Push.
现在，我将在本地提交更改，然后将其推送到服务器。 添加，提交，推送。
C:\Code52\DownmarkerWPF>git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: src/MarkPad/Constants.cs
#
no changes added to commit (use "git add" and/or "git commit -a")
C:\Code52\DownmarkerWPF>git add .
C:\Code52\DownmarkerWPF>git commit -m "#82 - Added .mkd extension support"
[master 17c5704] #82 - Added .mkd extension support
1 files changed, 1 insertions(+), 1 deletions(-)
C:\Code52\DownmarkerWPF>git push
Password:
Counting objects: 9, done.
Delta compression using up to 12 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 453 bytes, done.
Total 5 (delta 4), reused 0 (delta 0)
To https://shanselman@github.com/shanselman/DownmarkerWPF.git
792d099..17c5704 master -> master
Cool, so now I can see on the website that my issue #82 has been associated with my change because I used the number in the commit message.
很酷，现在我可以在网站上看到我的问题＃82与更改有关，因为我使用了提交消息中的数字。
Now I'll let the Project Administrators know where they can get it by pressing Pull Request on the website.
现在，我将通过按网站上的“拉取请求”，让项目管理员知道在哪里可以得到它。
Now I wait some number of minutes, hours or days for the owner of the project to accept my request. It's totally up to them what they accept and what acceptance criteria they have.
现在，我需要等待几分钟，几小时或几天才能让项目的所有者接受我的请求。 他们接受什么以及他们拥有什么接受标准完全取决于他们。
Here's my fix, now accepted, merged and closed by the Project Administrator. They will then close the issue.
这是我的修复程序，现已由项目管理员接受，合并和关闭。 然后，他们将解决问题。
Open Source isn't as scary as it seems. Go out there now and offer your help, time and assistance to your favorite project. Promote them, use them, fix their spelling and bugs. You can play with the Code 52 guys in their chat room on Jabbr or learn all about the project at the Code 52 website.
开源并没有看起来那么可怕。 现在就去那里，为您喜欢的项目提供帮助，时间和帮助。 推广，使用它们，修复其拼写和错误。 您可以在Jabbr的聊天室中与Code 52的伙计一起玩，或在Code 52网站上了解有关该项目的所有信息。
扫一扫
983
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
