之前用 SAE 的时候学了点 svn，后来发现还是 Git 先进，再后来就把注册许久不用的 Github 账号拿出来捣鼓，结果对 pull request 很迷惑。
Update:
[上一秒] pull 不是拉么？怎么地想也感觉是 push request 才对。
[下一秒] 哦！对作者来说是 pull 。。。
那就是两者一点都不搭边咯，一个是 CLI 的命令，一个是 Github 上概念性的东西。
仅有的幸福2017-04-28 09:08:25
我来说的更清楚一些吧，之前的答案和讨论都似是而非，并未直指真相。
Github 上的 pull request 和 git pull 并非完全没有关系，不过和它关系最近的则是另外一个命令 git request-pull。
先说概念上的解释。可能多数人（包括题主）会这样理解 pull request：
我，提交一个请求，把我的改动整合到 upstream（上游，通常代表你的 fork 的来源）去
这么一来，感觉应该是 push request 最贴切，因为这个动作完全是我主动的嘛！
然而这样理解忽略了一个前提：你有往 upstream 去 push 的权限吗？换言之，你能直接写 upstream 吗？
这要分两种情况（对应了两种基于 Git 的工作流）：
归根结底，产生这一误会的缘由在于不完全清楚 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。当你做出
请求的时候，其实背后执行的是 这个子命令。这个子命令的（主要）签名如下：
这条命令生成了一个摘要，其中包含了变更记录（以 commit 为单位）和用于抓取这些变更的地址。摘要以固定格式的纯文本输出到 stdout 去，你可以重定向然后编写代码做后续处理。Github 就是这样来分析每一个bash$ git request-pull <start> <url> [<end>]
pull request 的，因此能看到对应的 commit，时间，作者等等信息。
git pull 去指定地址（包含在 git request-pull上游作者在收到
之后若选择接受，Github 则调用 git pull 去指定地址（包含在
