Pull Request Basics
I've dropped my share of git bombs and still do, so I know it can be a real pain in the ass — and a bit embarassing — to skip a rebase/pull/merge when working on a pull request, so here's a generic quick reference for the standard GitHub contribution workflow. Every project has it's own guidelines but this should cover the basics.
Fork
Fork the original repo on GitHub and clone it locally.
$ git clone git@github.com:you/repo.git
$ cd repo
Add upstream
Add the original repository as a remote named upstream. This gives you a to pull remote changes.
$ git remote add upstream git://github.com/original/repo.git
Branch
Create a topic branch. If your pull request is a new feature, you
will probably need to work from a development branch rather than
master. For example, many projects use a develop or *-wip branch
for this. A hot fix on the other hand might make more sense targeted at
master. The remaining instructions will assume master but it's important
to make sure your work is branched from an appropriate commit.
$ git checkout -b feature-or-bug-fix
Hack away
Make your changes, add tests and commit.
$ git commit -am "fix the things"
Pull upstream
Checkout master and pull in any upstream changes. You should not run
into any merge conflicts at this point since all work is being done on a
topic branch.
$ git checkout master
$ git pull upstream master
Rebase
This is the fun bit. If there are conflicts between your branch and the pulled in remote changes, you will need to merge them. Merging is outside the scope of this post but it's a good idea to rebase regularly.
$ git checkout feature-or-bug-fix
$ git rebase master
Push
Push the topic branch to your remote fork.
$ git push origin feature-or-bug-fix
Pull request
Submit the pull request. As noted above, be sure that you target the appropriate branch — namely the one you branched from originally.