之前用 SAE 的时候学了点 svn，后来发现还是 Git 先进，再后来就把注册许久不用的 Github 账号拿出来捣鼓，结果对 pull request 很迷惑。
Update:
[上一秒] pull 不是拉么？怎么地想也感觉是 push request 才对。
[下一秒] 哦！对作者来说是 pull 。。。
那就是两者一点都不搭边咯，一个是 CLI 的命令，一个是 Github 上概念性的东西。
公开的库对吧，你对这个库pull你的修改，然后这个库的作者就可以看到你的请求，并决定是否给你合并到他的本来的库上。
我来说的更清楚一些吧，之前的答案和讨论都似是而非，并未直指真相。
Github 上的 pull request 和 git pull 并非完全没有关系，不过和它关系最近的则是另外一个命令 git request-pull。
先说概念上的解释。可能多数人（包括题主）会这样理解 pull request：
我，提交一个请求，把我的改动整合到 upstream（上游，通常代表你的 fork 的来源）去
这么一来，感觉应该是 push request 最贴切，因为这个动作完全是我主动的嘛！
然而这样理解忽略了一个前提：你有往 upstream 去 push 的权限吗？换言之，你能直接写 upstream 吗？
这要分两种情况（对应了两种基于 Git 的工作流）：
- 有权限——那么你完全没必要 fork & pull request，既然作者给了你权限，你就直接 clone 下来当作自己的 repo 去操作就好了，何必多此一举？
- 没权限——既然没权限，何来 push request 一说？
归根结底，产生这一误会的缘由在于不完全清楚 pull request 工作流的工作原理。对于 pull request 动作的正确描述应该是这样的：
我，发起一个请求（以 Github 来说就是一个 HTTP 请求调用对应 API，然后由 Github 在后端执行
git request-pull，详见后文），这个请求（HTTP request 里的 request）是请求（pull request 里的 request）上游的作者去拉取（pull request 里的 pull）来自于我的 fork 里的变更。
这才是正确的理解。
最后来说说 git request-pull。当你做出 pull request 请求的时候，其实背后执行的是 git request-pull 这个子命令。这个子命令的（主要）签名如下：
bash$ git request-pull <start> <url> [<end>]
这条命令生成了一个摘要，其中包含了变更记录（以 commit 为单位）和用于抓取这些变更的地址。摘要以固定格式的纯文本输出到 stdout 去，你可以重定向然后编写代码做后续处理。Github 就是这样来分析每一个 pull request 的，因此能看到对应的 commit，时间，作者等等信息。
上游作者在收到 pull request 之后若选择接受，Github 则调用 git pull 去指定地址（包含在 git request-pull 产生的信息里）拉取代码。上游作者自然有写入 upstream repo 的权限，于是一个完整的流程得以实现。
建议去阅读一下 Git 官方手册，特别是这一章：分布式 Git - 为项目作贡献，读完之后我包你受益匪浅。