If you created a fork of a repository, it is because you are not a direct contributor of the original project, or simply you don't want to make a mess in other people's work before becoming familiar with the code.

However, at a certain point, you realize your work can be useful even for the original project: you realize a better implementation of a previous piece of code, you add a missing feature, and so on.

So, you find yourself needing to notify the original author that you did something interesting, asking him if he wants to take a look and, maybe, integrate your work. This is the moment when pull requests come in handy.

A pull request is a way to tell the original author Hey! I did something interesting using your original code, do you want to take a look and integrate my work, if you find it good enough? This is not only a technical way to achieve the purpose of integrating work, but it is even a powerful practice for promoting code reviews (and then the so-called social coding) as recommended by eXtreme Programming fellows (for more information, visit: http://en.wikipedia.org/wiki/Extreme_programming).

Another reason to use a pull request is that you cannot push directly to the upstream remote if you are not a contributor of the original project: pull requests are the only way. In small scenarios (such as a team of two or three developers that works in the same room) probably the fork and pull model represents an overhead, so it is more common to directly share the original repository with all the contributors, skipping the fork and pull ceremony.