Git - Contributing Code on GitHub

In the last article, we looked at Git rebase and Git merge. In this article, I’ll take everything we’ve learned so far in our Git series and will demonstrate how to utilize this information in order to contribute code to GitHub. I’ll be using a project called grunt\node.js to demonstrate, but no worries—you don’t need to know anything about Node.js in order to understand what I’ll be doing. The code itself isn’t really important—it’s the Git operations we’re concerned with.

First off, I choose a project that I wanted to contribute to. Grunt template for sending emails—very nice to work with and at some point I’ll write about it.

In order for me to be able to start working on a project, I need to have my own version of it to which I can add to. I can’t push code to a repository that isn’t mine. So I’ll click the Fork button.

Right after clicking, a version for me will be created in a repo. This new version is identical to the original, but with one significant difference—the repo is mine and I can make changes to it. Now I go into my local computer so that I’ll be able to make changes to the code. And how will I do this? Using clone, which we learned about in a previous article in the series.

We can run git clone with the repo’s address in SSH or HTTPS. These are different methods for connecting, and even though SSH is easier, here we’ll use HTTPS and we’ll save SSH for another time.

git clone https://github.com/barzik/grunt-email-boilerplate.git

^{clone example}

Now I make the changes. Notice that there are several branches in the repo—in order to pass between them I can type git co BRANCHNAME. There are projects that ask us to push all the changes to develop, while some prefer to be in the master. Others still will ask to put it in a separate branch. If you’re not sure, you can have a look at the log of changes, or ask the developer. In this case, I saw that it was a small project, so I decided to push my changes to the master branch.

After I’ve made the changes, I’ll run commit. We talked about commit in a previous article, so I won’t go into it here.

$ git commit -m'Adding image as paths variable'
[master fc75522] Adding image as paths variable
1 file changed, 11 insertions(+), 9 deletions(-)

After the change, the time has come to run push. I’ll run push on my master branch:

$ git push origin master
Counting objects: 10, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 463 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
To git@github.com:barzik/grunt-email-boilerplate.git
  638a710..fc75522  master -> master

Now my repo is different from the original repo:

If I’m satisfied, I can run a pull request—I can simply go into my repo on GitHub, and there the interface itself will offer to run the pull request:

After clicking on the button, I get to the comparing changes page. Here I can examine the changes between my code and that of the original repo. If there are conflicts, they’ll appear here.

^{Checking the difference of the pull request}

What happens if there are conflicts? It could happen if up until I made the pull request the original code was changed. In this case, I need to pull the changes from the original code using git pull or git rebase. How do I do this, when the repo that I’m getting updated from is mine (barzik), not the original (dwightjack)? The answer is simple, I need to set an additional remote, that’s not the origin. And how to do this? Easy:

git remote add upstream git@github.com:dwightjack/grunt-email-boerplate.git

If I run the command git remote -v, I’ll see all of the sources:

$ git remote -v
origin git@github.com:barzik/grunt-email-boilerplate.git (fetch)
origin git@github.com:barzik/grunt-email-boilerplate.git (push)
upstream git@github.com:dwightjack/grunt-email-boilerplate.git (fetch)
upstream git@github.com:dwightjack/grunt-email-boilerplate.git (push)

The command, git pull upstream master, will bring me the master of dwightjack’s repository. I can of course run rebase or pull & merge. After I’ve resolved conflicts and/or updated, I’ll push everything again to my master (origin) and will go back to the pull request step.

After checking out the changes, I’ll write a message to the repository owner—it’s important that the message will be clear, and will explain the significance of the changes. In this case, it’s just a simple change, so I didn’t write too much.  

^{Pull request message}

Every project has its standard for texts about the pull requests and I’ll get into this in a future article.

After writing the message and launching the pull request, whoever maintains the code can approve the pull request, or write to me about the changes that they want to see. Anyone can see the pull requests and write about them.  If I want to change the pull request, nothing could be easier—just make changes to the local version, run another push to the branch from where the pull request came, and make sure in the GitHub’s interface that the changes went through.

If my code gets accepted, anyone in the world can benefit from my contribution. Long live open source!

Up next, we’ll take a look at Git Alias.

About the author: Ran Bar-Zik is an experienced web developer whose personal blog, Internet Israel, features articles and guides on Node.js, MongoDB, Git, SASS, jQuery, HTML 5, MySQL, and more. Translation of the original article by Aaron Raizen.