[Edit, May 2018: git pull is no longer a shell script and a few details are different in modern Git. Pull also now has recursion options that make it more useful with submodules. This answer ignores the submodules.]
The git pull script is meant as a convenience method for invoking git fetch followed by git merge (or, with git pull --rebase, invoking git fetch followed by git rebase).
The first extra argument to git pull tells it which remote to give to the fetch operation:
git pull origin
for example, means to fetch from origin. If you leave this out, Git uses the current branch’s remote:
$ git branch
* master
$ git config --get branch.master.remote
origin
The second (and any additional) arguments to git pull tell it which branch or branches to merge in. These are the names of the branches as found on the remote. For instance, suppose you create a new branch feature2 that tracks origin/feature:
$ git checkout -b feature2 origin/feature
If you now want to fetch from origin to pick up new commits added to their feature branch, but merge them in to your local feature2 branch:
$ git pull origin feature
If you leave out the branch name(s), git uses the current branch’s merge:
$ git config --get branch.feature2.merge
feature
Note that if you list multiple branch names, Git will do an “octopus merge”. In my experience, this usually surprises people the first time: they think git pull remote br1 br2 will run git fetch followed by a series of separate git merge-s on each branch, but that’s not what happens.