Let's actually contribute some code back to the open source project.

We already created a fork of the hello-treehouse Project earlier.

Let's clone your version of the repository locally, make the fix and

create a pull request.

For this video we'll use your local environment and

I'll walk you through each step.

First, let's make sure we have a copy of the fork repository locally.

To find the fork repository from the GitHub dashboard,

click on the context switch or on the top left, and choose our organization's name.

Now you should see a list of repositories on the right.

Let's click the hello-treehouse repository.

We'll copy the URL from GitHub and then go to our terminal.

We'll run git clone and paste the URL.

Then we'll move into the hello-treehouse folder and I'll clear our console.

To make a change, the first thing we'll want to do is create a branch.

By creating a branch, we're creating an easy way for us to create a pull request.

If you remember in the git basics course you can create a branch using git checkout

-b and let's call this branch fix treehouse-bug.

Great now we have a new branch and git has automatically moved us on to that branch.

Now let's make the simple fix.

If I open up the start.rb file using vim, we can see, there's the error.

We're raising a runtime error that says,

don't start it will explode, let's remove that.

I'm gonna save this file, and then now let's add this change to git,

And we'll create a new commit.

Add a simple commit message, And then Save the commit.

Last but not least we need to push this change to GitHub.

We'll do that by running git push origin fix-treehouse-bug, and add our user name.

All right, we've created the branch, made the fix, and pushed it up to GitHub.

Now, let's go create our pull request.

Let's go back to the fork of the hello-treehouse project on

the GitHub site.

You'll notice now that there's this new section called recently pushed

branches are fixed treehouse bug branches here and now we can

easily create a pull request by clicking on the Compare and pull request button.

This looks a lot like the pull request window we saw earlier in the course, but

there is one big difference.

This pull request is comparing our fork to the original project.

This means that we're trying to move this code from our fork into the original

projects master branch.

This is how most open source projects get changes from contributors.

The contributor forks creates a branch and then opens a pull request between their

forks branch and the original projects master branch.

Now let's fill in this pull request form,

similar to how we submitted the open source issue let's add a clear name.

GitHub already provides a sub title from the commit that we created, and

then let's describe the change that we made.

Great, for a more complex pull request or a real open source project,

there are a few other guidelines that are worth following.

These extra guidelines are often spelled out in the projects read me or

in a contributing file, but I'll share a few now.

It's best to include tests, every time you make a change to an open-source project,

add a unit test to cover what you've changed.

This helps maintainers know that the code does exactly what you say it does.

Include screenshots if it's a visual change.

This saves maintainers time so

they don't need to test out your change in a variety of browsers.

Always make your changes in the style of the project.

Even though you may have a preferred way of solving a coding problem,

or a certain style you'd like to stick to make sure your change fits in with

the larger project.

Now let's add a cross reference back to the issue that we created earlier in

the course.

Let's type a # sign, and find the issue we created in the last video.

Once we find it we can click Enter and

it will populate a link to the issue inside the pull request.

If we use the phrase Closes #1 when this

PR gets merged the issue will be automatically closed.

Now all we need to do is click Create pull request.

Now it's up to the maintainer to decide if they'd like to merge the changes that

you've created.

>> It's important to remember that not all pull requests will get merged.

This doesn't mean your poor quest was bad or wrong, sometimes the maintainer will

disagree with the approach or know about another change that's already underway.

Submitting a pull request at all is a big accomplishment.

So don't worry if your pull request isn't merged right away or at all.

Well, that's it you're well on your way to becoming a GitHub pro.

>> If you wanna check out even more ways to use GitHub,

head over the guides.github,com.

Remember, if you get stuck, you can ask for help in the Treehouse community.

>> Thanks for taking this course with us, we'll see around Treehouse.