为什么git 'pull request'不叫'push请求'?

为了更好地理解它并永远记住它，你需要描绘它。

想象一个大的、活的树(作为您的存储库)。这棵树太坚固了，你不能将一个分支推入或添加一个新部分(象征创建一个新分支或你将代码推入其中)，相反，你必须要求这棵树将一个分支拉入主干或从你那里获得更改。

术语“拉请求”来自于分布式的本质。而不是仅仅将您的更改推入存储库(就像您使用集中式存储库所做的那样，例如Subversion)，您将单独发布您的更改，并要求维护者拉入您的更改。然后维护者可以查看更改并执行所谓的拉取。

所以你基本上是“请求”那些对你想要贡献的回购有写权限的人，从你的回购中“拉”出来。

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

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

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

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

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

从这里可以得出结论，选择术语的原因是使管理工作是一流劳动的观点合法化。此外，混乱关于这个术语选择的原因可能是非经理员工自然有不同的观点。

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

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

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

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

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

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

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

主要原因是你不能push到别人的回购。相反，您必须请求他们pull您的分支。

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

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

repo A：  repoB：
b        c
|        |
a        a

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

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

• 你git push，失败了。因为A和B冲突。
• 你git push --force和成功。但是，commit c已经没有了。它变成了

repo A：  repoB：
b        b
|        |
a        a

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

您必须在push之前消除冲突。比方说，你必须先pull上游回购并获得

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

然后你可以push。

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

但是，它只适用于如果没有其他推送请求。

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

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

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

根据经验，你可能最终会做出一个没有冲突的出色的推送请求。恭喜你，但是有成百上千的推送请求。如果所有者首先接受另一个推送请求，则必须再次执行pull和push。

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

• 消除矛盾。
• 合并分支。

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

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

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

所以，pull操作自然是选择。这就是为什么有pull请求而没有push请求的原因。

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

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

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

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

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

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

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

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

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

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

简单地说，因为您请求Pull(获得一份副本)代码，但在Push中，您请求通过将代码推入目标来集成代码。