Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
Contribute some code back into an open source project!
Further reading
It is important to remember that not all Pull Requests will be merged. Try to keep your pull requests valuable to the main project by providing documentation, a bug fix, or a new feature. Avoid “gotcha” pull requests that only fix a single bit of wording. Regardless, not all pull requests get merged (and I have had dozens that get closed without merging). Don’t feel bad: keep at it and with more context and experience you will be an open source machine in no time.
Let's actually contribute some code
back to the open source project.
0:00
We already created a fork of
the hello-treehouse Project earlier.
0:04
Let's clone your version of
the repository locally, make the fix and
0:07
create a pull request.
0:12
For this video we'll use
your local environment and
0:13
I'll walk you through each step.
0:16
First, let's make sure we have a copy
of the fork repository locally.
0:19
To find the fork repository
from the GitHub dashboard,
0:23
click on the context switch or on the top
left, and choose our organization's name.
0:26
Now you should see a list of
repositories on the right.
0:31
Let's click the hello-treehouse
repository.
0:34
We'll copy the URL from GitHub and
then go to our terminal.
0:37
We'll run git clone and paste the URL.
0:42
Then we'll move into the hello-treehouse
folder and I'll clear our console.
0:47
To make a change, the first thing
we'll want to do is create a branch.
0:53
By creating a branch, we're creating an
easy way for us to create a pull request.
0:57
If you remember in the git basics course
you can create a branch using git checkout
1:01
-b and
let's call this branch fix treehouse-bug.
1:07
Great now we have a new branch and git has
automatically moved us on to that branch.
1:12
Now let's make the simple fix.
1:16
If I open up the start.rb file using vim,
we can see, there's the error.
1:19
We're raising a runtime error that says,
1:26
don't start it will explode,
let's remove that.
1:29
I'm gonna save this file, and
then now let's add this change to git,
1:32
And we'll create a new commit.
1:39
Add a simple commit message,
And then Save the commit.
1:41
Last but not least we need to
push this change to GitHub.
1:50
We'll do that by running git push origin
fix-treehouse-bug, and add our user name.
1:53
All right, we've created the branch,
made the fix, and pushed it up to GitHub.
2:06
Now, let's go create our pull request.
2:11
Let's go back to the fork of
the hello-treehouse project on
2:14
the GitHub site.
2:17
You'll notice now that there's this
new section called recently pushed
2:18
branches are fixed treehouse bug
branches here and now we can
2:22
easily create a pull request by clicking
on the Compare and pull request button.
2:26
This looks a lot like the pull request
window we saw earlier in the course, but
2:33
there is one big difference.
2:37
This pull request is comparing
our fork to the original project.
2:38
This means that we're trying to move this
code from our fork into the original
2:42
projects master branch.
2:47
This is how most open source projects
get changes from contributors.
2:48
The contributor forks creates a branch and
then opens a pull request between their
2:52
forks branch and
the original projects master branch.
2:57
Now let's fill in this pull request form,
3:00
similar to how we submitted the open
source issue let's add a clear name.
3:02
GitHub already provides a sub title
from the commit that we created, and
3:07
then let's describe
the change that we made.
3:11
Great, for a more complex pull request or
a real open source project,
3:24
there are a few other guidelines
that are worth following.
3:28
These extra guidelines are often
spelled out in the projects read me or
3:32
in a contributing file,
but I'll share a few now.
3:35
It's best to include tests, every time you
make a change to an open-source project,
3:38
add a unit test to cover
what you've changed.
3:43
This helps maintainers know that the code
does exactly what you say it does.
3:46
Include screenshots if
it's a visual change.
3:50
This saves maintainers time so
3:53
they don't need to test out your
change in a variety of browsers.
3:55
Always make your changes in
the style of the project.
3:59
Even though you may have a preferred
way of solving a coding problem,
4:03
or a certain style you'd like to stick
to make sure your change fits in with
4:07
the larger project.
4:11
Now let's add a cross reference back
to the issue that we created earlier in
4:12
the course.
4:17
Let's type a # sign, and find the issue
we created in the last video.
4:18
Once we find it we can click Enter and
4:24
it will populate a link to
the issue inside the pull request.
4:26
If we use the phrase Closes #1 when this
4:29
PR gets merged the issue will
be automatically closed.
4:33
Now all we need to do is
click Create pull request.
4:38
Now it's up to the maintainer to decide
if they'd like to merge the changes that
4:43
you've created.
4:47
>> It's important to remember that not
all pull requests will get merged.
4:48
This doesn't mean your poor quest was bad
or wrong, sometimes the maintainer will
4:52
disagree with the approach or know about
another change that's already underway.
4:57
Submitting a pull request at
all is a big accomplishment.
5:01
So don't worry if your pull request
isn't merged right away or at all.
5:05
Well, that's it you're well on
your way to becoming a GitHub pro.
5:09
>> If you wanna check out
even more ways to use GitHub,
5:13
head over the guides.github,com.
5:16
Remember, if you get stuck, you can ask
for help in the Treehouse community.
5:18
>> Thanks for taking this course with us,
we'll see around Treehouse.
5:22
You need to sign up for Treehouse in order to download course files.
Sign up