Git Pull vs. Pull Request

A pull request is requesting the maintainer of a repository to git pull in some changes (as the name already suggests). GitHub provides an additional easy to use interface that simplifies review of such a request.
You don't need to use it to merge in some branch. But you can use it and it may be helpful to recheck whether all changes are ready to be merged. If you don't want or need that additional safety you can simply git merge the branch.

---

git itself also has a command that creates a pull request, designed for the use in mailing lists. You can request the generation with the git request-pull command. In fact it is required to hand in a pull request for some projects using this command! The output of the command looks similar to this (taken from the official git homepage):

$ git request-pull origin/master myfork
The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40:
  John Smith (1):
        added a new function

are available in the git repository at:

  git://githost/simplegit.git featureA

Jessica Smith (2):
      add limit to log function
      change log output to 30 from 25

 lib/simplegit.rb |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

If you use git pull, you pull the changes from the remote repository into yours.

If you send a pull request to another repository, you ask their maintainers to pull your changes into theirs (you more or less ask them to use a git pull from your repository).

If you are the maintainer of that repository, it seems you're making it a bit more difficult by pretending you're playing two roles in that workflow. You might as well merge locally your development branch into your master branch and push that master branch into your GitHub repository directly.

(As a side note, if you're new to Git, I'd suggest using git fetch and then git merge instead of git pull. git pull is effectively git fetch followed by git merge, but doing them separately gives you better control over potential conflicts.)