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 the original repo on GitHub and clone it locally.
$ git clone email@example.com:you/repo.git $ cd repo
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
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
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
Make your changes, add tests and commit.
$ git commit -am "fix the things"
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
$ git checkout master $ git pull upstream master
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 the topic branch to your remote fork.
$ git push origin feature-or-bug-fix
Submit the pull request. As noted above, be sure that you target the appropriate branch — namely the one you branched from originally.