我想把一些东西推到别人的回购中。

我没有推(或拉)的权限。

所有者/合作者拥有权限。它们既能推又能拉。我推不动。

所以，我要求他们执行我的拉——这间接地意味着我要求他们接受我的推。

所以，没有推送请求。只是为了拉一把。并接受一个推动。

因此，这是一个“pull”请求。而不是“push”请求。

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

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

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

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

任何需要一段解释的术语，都表明术语的选择不是直观的，具有复杂性或片面性。上面有很多写得很好的解释，所以我就不再赘述了，但这里是我对git中的push和pull术语感到沮丧的评论。

考虑门上正常的“推”和“拉”标签。

它是从即将开门的人的眼睛里解读出来的。

如果是“推”，这个人就会“推”。

如果它说“拉”，自然会有一个把手，用来把门拉向自己。

现在想象一下，如果gitHub制造了门，并在门上写了“拉”，只是为了让门从另一端被拉，而不是从你的一端被拉(所以在某种程度上，这是正常世界中的推!)。然后，你会用你的大脑来对抗直觉思维，并将拉门转化为推门。

正是这种想法导致了这种混乱。

我们大脑中依赖直觉和原始解释的系统会进入一个冲突区。

我只是选择接受git Pull和Push请求的这个异常定义，并将其作为生活中一旦遇到的许多例外之一，然后继续前进。

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

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

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

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

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

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

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

git拉取意味着我从存储库中拉取。

git推送意味着我正在推送到存储库。

一个拉取请求自然会随之而来，我在问回购所有者我可以从他们的存储库中拉取，对吧?

错误，拉请求意味着我请求(本质上)推送到存储库。

这背后的假定逻辑是，存储库现在本质上是命令的所有者。但如果是这种情况，那么从存储库中检索代码将通过git push实现。因为如果存储库是所有者，那么他们就全权负责将代码推送给您。但是没有。不一致是关键。

公认的答案是，“push”听起来像是您在强迫存储库进行更改，但这毫无意义，因为您看不到它是一个REQUEST。请求，就其本质而言，并不是强加于人的。