站在回购方的角度想想!! 拉请求-这意味着，Git会告诉回购，你有一些外部的东西要进入，所以从回购的角度来看，这是一个拉请求。

恐怕大多数答案都回答了“pull request”是什么意思?“push request”是什么意思?而不是OP的问题:为什么它被称为拉请求而不是推请求?

通常这种问题替换是可以接受的，但在这种情况下，OP显然知道这些替换问题的答案，所以回答它们并不是很有帮助。

只有在GitHub创造了这个词的人知道确切的答案。然而，似乎很明显，这个术语选择反映了类似以下关于“从外部进入存储库的更改”现象的观点:维护者执行操作(拉)。

然而，请求也是一个动作，动作的执行者不是维护者，而是提交者(他做了更多的动作，即工作)。因此，术语“拉请求”造成了关于代理是谁的混乱。最终产生混淆的原因是请求的递归性质:请求既是主代理的操作，也是第二个代理对未来操作的请求。

这种情况非常类似于现在常见的语言结构，如“我们建造了我们的房子”(用来代替“我们付钱给别人建造我们的房子”)，因为主要行动的责任从明显的原始代理转移到履行管理社会角色的次要代理。

人们可以由此得出结论，选择术语的原因是使“管理工作是一流劳动”这一观点合法化。此外，对这一术语选择感到困惑的原因可能是，非管理者的员工自然有不同的观点。

这样思考。本地存储库vs远程存储库。

当你从本地推送。(git push) -换句话说，远程存储库正在从您(本地)拉代码。

你在提出要求。所以，问问你自己，

你想要远程存储库从你拉代码吗?-拉请求。

这不仅仅是主观和客观的问题。如果后面实际上是一个推送操作，那么说“I request to push”也是合乎逻辑的。

主要原因是你不能推到别人的回购。相反，你必须要求他们拉你的树枝。

那么，为什么GitHub不允许你请求推送呢?直观地说，如果经理们能够选择接受或拒绝我的推送，这种方法也有意义，就像他们选择接受或拒绝我的回购一样。

---

让我们先看看push。假设有两个回购，A和B:

repo A：  repoB：
  b        c
  |        |
  a        a

A和B分别在提交A时提交B和c。

然后你从A推到b，有两种结果。

你不推就失败了。因为A和B冲突。 你得到了推动——力量和成功。但是，commit c已经没有了。它变成了

repo A：  repoB：
  b        b
  |        |
  a        a

这不是你想做的，对吧?所以你需要另一种方法。

---

你必须在推之前消除矛盾。比如说，你必须先拉回上游回购，然后得到

repo A：  repoB：
  d
  |\
  b c      c
  |/       |
  a        a

然后你就可以推了。

这就是推送请求系统的样子:贡献者首先处理冲突，然后请求进行推送操作来更改上游回购。也许现在看起来很整洁。上游回购的管理者可以选择接受或拒绝贡献者的推送请求。一切工作。

---

但是，它只在没有其他推送请求的情况下工作。

假设在拉出上游分支并处理了冲突之后，您刚刚发出了一个推送请求。你以为你已经完成了，但事实上没有。当您提取代码时，您惊奇地发现上游回购的所有者刚刚做了一个新的提交e。现在，情况变成:

repo A：  repoB：
  d        e
  |\       |
  b c      c
  |/       |
  a        a

好的。现在，您必须再次将新的提交拉到您的回购并发出新的推送请求。别忘了，可能会有一些新的代码提交给上游……理论上你可能要一直循环下去。

根据经验，你可能最终会做出一个没有冲突的出色的推送请求。恭喜你，但是有成百上千的推送请求。如果用户首先接受了另一个推送请求，则必须再次进行拉推操作。

---

因此，要使一个贡献工作整齐，所请求的操作必须有两部分:

消除矛盾。 合并分支。

而且必须由主人来做。否则，所有人必须:

批准贡献者的新代码。 认可贡献者消除冲突的方式。

但是就像这个例子一样，当贡献者消除冲突时，可能会引入更多的冲突。

所以，拉拔操作自然是选择。这就是为什么只有拉请求而没有推请求。

拉取请求是生成一个请求，要求repo拉取您的更改。

拉请求:我请求你拉我的。