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

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

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

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

Pull请求可以让你告诉其他人你已经推送到GitHub存储库分支的更改。一旦打开了拉取请求，您就可以与协作者讨论和检查潜在的更改，并在将更改合并到基本分支之前添加后续提交。 Github的解释

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

这不仅仅是主观和客观的问题。如果后面实际上是一个推送操作，那么说“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

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

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

---

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

消除矛盾。 合并分支。

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

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

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

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

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

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

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

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

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

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

既然我不被允许出手，我就很好地向回购所有者提出请求，让他们决定退出

---

谁可以将代码推送到存储库?

如果有人(可能是邪恶的、没受过教育的或未知的)能够来这里说，我刚刚把这个推到你的主分支，搞砸了你所有的代码，哈哈哈!?

你肯定不希望他那样做吧。默认情况下设置了一个安全网，所以没有人可以推动你的回购。你可以把其他人设置为合作者，然后他们可以推动。你会把这样的机会给你信任的人。

所以如果你不是一个合作者，尝试推送，你会得到一些错误，表明你没有权限。

---

那么，其他开发商如何推动他们没有获得许可的回购呢? 你不能给每个人访问权限，但你想给其他人一个出口/入口点，这样他们就可以“向回购所有者请求将此代码拉入回购”。简单地说，通过使回购可访问，他们可以分叉…在自己的fork中进行更改。将他们的更改推到他们自己的fork上。一旦它在他们自己的远程回购:

他们从他们的分叉发出一个拉取请求，上游回购的所有者(你不能直接推到)将决定是否合并拉取请求。

---

换个角度解释一下:

推送是指你(通常)不需要任何人批准的事情，例如，你总是可以推送到你自己创建并一直致力于的功能分支。

虽然您可以在您自己创建的两个分支之间创建一个拉请求，并可以将其推入。你几乎从不这样做。

当我致力于一个大型功能并且已经批准了我的pull请求时，我便这么做了，但我需要做出一些棘手的改变，所以我便针对我现有的分支创建了PR。

如果你需要别人的认可，那你就不要强迫别人。你希望别人:

回顾你的分支 给你批准 去拿你的树枝 与master合并

（3+4 = git pull）

---

顺便说一句，你可能会问，为什么它不被命名为“合并请求”?

我发现最好的答案是，如果你只是直接提交到main -没有多个功能分支，那么你永远不会有merge(两个父组成一个子)提交。所有的提交都是对前一个提交的新提交。因此，名称“合并提交”将不适用。

---

还有一个半相关的问题，我推荐阅读git推送到底发生了什么?为什么git push不像git merge那样被考虑?

如果您在存储库中有一个代码更改，并希望将其移动到目标存储库，那么:

“Push”是你强制目标存储库中出现的更改(git Push)。 “Pull”是目标存储库抓取你的更改，以呈现在那里(git从另一个repo拉)。

“拉取请求”是您请求目标存储库获取您的更改。

“推送请求”将是目标存储库请求您推送更改。