用于将分支与官方存储库合并的术语是“拉取请求”。这很令人困惑，因为我似乎要求将我的更改推送到官方存储库。
为什么称为拉取请求而不是推送请求？
答案 0 :(得分：269)
如果您的存储库中有代码更改，并且想要将其移动到目标存储库，那么：
git push）。 git pull来自其他仓库）。“拉取请求”是您请求目标存储库取悦您的更改。
“推送请求”将是请求您推送更改的目标存储库。
答案 1 :(得分：70)
当您发送拉取请求时，您要求（请求）官方回购所有者从您自己的回购中提取一些更改。因此“拉动请求”。
答案 2 :(得分：27)
谁可以将代码推送到存储库？
如果任何人（可能是邪恶的或未受过教育的或未知的）能够来这里说，我只是把它推到你的主分支并搞砸了你所有的代码HAHAHA！？
当然，你不希望他这样做。默认设置安全网，因此没有人可以推送您的回购。您可以 set others as a collaborator，然后他们就可以推送。您可以向您信任的人提供此类访问权限。
因此，如果您不是合作者并尝试推送，则会收到一些错误消息，表明您未获得许可。
那么其他开发者如何推动回购他们没有被允许推送？
您无法向所有人提供访问权限，但您希望为其他人提供出口/入口点，以便他们向回购权所有者发出 pull 这个代码进入了回购＆＃39;。简单地说，通过使repo可访问，他们可以分叉...在他们自己的fork中进行更改。 将他们的更改推送到他们自己的分支。一旦他们进入他们自己的远程仓库：
他们从他们的分支发出拉取请求，而上游回购的所有者（你不能直接推送）将决定是否合并拉取请求。
我还建议您阅读What exactly happens in a git push? Why isn't a git push considered just like a git merge?
这个与半相关的问题答案 3 :(得分：19)
拉取请求：我请求给你拉我的。
答案 4 :(得分：3)
恐怕这些答案中的大多数都回答了“请求”是什么意思？或“请求”是什么意思？，而不是OP的问题。问题：为什么是拉请求而不是推请求？
通常这种问题替换是可以接受的，但是在这种情况下，很明显，OP知道这些替换问题的答案，因此回答它们不是很有帮助。
只有创造了该术语的GitHub人员才能确定。但是，显然，该术语选择反映了类似以下观点，涉及“从外部进入存储库的更改”现象：维护者执行操作（拉动）。
但是，请求也是一个动作，该动作的执行者不是维护者，而是提交者（谁做了更多的动作，即工作）。因此，“拉取请求”一词会引起对代理人身份的混淆。最终，混淆是由请求的递归性质引起的：请求既是主代理的动作，又是第二代理对将来动作的请求。
这种情况非常类似于现在常见的语言结构，例如“我们盖房子”（代替“我们付钱给别人盖房子”），因为主要行动的责任已从明显的转变原始代理人转变为履行管理社会角色的次要代理人。
由此可以得出结论，术语选择的原因是合法化管理工作是一流的劳动力的观点。此外，对这种术语选择感到困惑的原因可能是非管理人员自然会有不同的观点。
答案 5 :(得分：1)
这是“请求”这个词，是这些行动的关键。你也可以把它想象成“我要求你接受我的工作，你接受吗？” - “拉动请求”。
起初有点混乱，但最终有道理。
答案 6 :(得分：1)
我想将某些内容推送到其他人的仓库中。
我没有推（或拉）的权限。
所有者/合作者具有权限。他们可以拉也可以推。我不能推。
因此，我要求他们从我这里进行拉取-这间接意味着我正在要求他们接受我的请求。
因此，无需请求推送。只为拉。并接受推送。
因此，一个“拉”请求。而不是“推送”请求。
答案 7 :(得分：1)
这不仅与主观和客观有关。如果实际上是后面的推送操作，则说“我请求推送”也是合乎逻辑的。
主要原因是您无法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，成功了。但是，提交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个请求的原因。
答案 8 :(得分：1)
拉取请求正在生成一个请求，要求存储库拉取您的更改。
答案 9 :(得分：0)
我认为这是一种愚蠢的用语，因为我想认为 I 想要向您推销某些东西，而不是反过来要求其他人要求添加地雷。因此，应将其更改为PUSH REQ。因为我是最活跃的部分箭头以相反的方式从我开始，而不是另一端的高飞。恕我直言。
答案 10 :(得分：0)
这样想。 。有两个人。 本地存储库 与 远程存储库。
<h1>Vertical Menu</h1>
<div class="vertical-menu">
<a href="#" class="active">Home</a>
<a href="#"><img src="https://www.tsishipping.com/storage/app/media/_mediathumbs/interstate%20shipping%20new%20mexico-img-3-386af11858050a81cdd53b7b6eeabdb6.png" alt="Girl in a jacket" height="16" width="18">Link 100</a>
<a href="#">Link 2</a>
<a href="#">Link 3</a>
<a href="#">Link 4</a>
</div>）-您将代码扔到远程存储库中。换句话说，远程存储库是您（本地）的拉动代码。 您正在请求某些内容。所以，问问自己，
答案 11 :(得分：0)
要更好地理解并永远记住它，您需要对其进行图像化。
想象一棵大的活树{作为您的仓库}。
这棵树太坚固了，您无法将分支推入其中或在其中添加新的部分{象征创建一个新分支，或者您将代码推入其中}，
相反，您必须要求树将树枝拉入树干或要求您进行更改。
“拉取请求”一词来自分布式性质。不仅仅是将更改推送到存储库中（就像使用集中式存储库（例如使用Subversion）那样），您还可以单独发布更改并要求维护者提取更改。然后，维护人员可以查看所做的更改并执行“ pull”操作。
因此，您基本上是“请求”那些拥有您要贡献的回购权的写权限的人，并从您的回购中“拉”钱。
通过拉请求，您可以将您已推送到GitHub上存储库中的分支的更改告知其他人。打开拉取请求后，您可以与协作者讨论和审查潜在的更改，并在更改合并到基础分支之前添加后续提交。 Github Explanation
这些大多取自其他堆栈溢出贡献者，但经过编辑和合并以更好地说明问题
答案 12 :(得分：0)
一个git pull意味着我正在从存储库中提取。
一个git push意味着我要推送到存储库。
很自然地，我会问回购所有者可以从他们的存储库中拉出请求，对吗？
错误，请求请求意味着我正在（本质上）请求推送到存储库。
其背后的逻辑是，存储库现在实质上是命令的所有者。但是，如果是这种情况，那么将遵循git push来执行从存储库中检索代码的操作。因为如果存储库是所有者，那么他们将全权负责将代码发布给您。但不是。不一致是关键。
已接受的答案指出，“推送”听起来像是您对存储库强加了更改，但这是零意义的，因为您忽略了它是一个请求。从本质上来说，请求不会强加于任何事物。