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

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

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

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

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

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

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

换个角度解释一下:

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

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

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

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

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

（3+4 = git pull）

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

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

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

我认为这是一个愚蠢的术语，因为我想认为我想把一些东西推给你，而不是反过来要求别人拉我的添加。所以应该改为PUSH REQ。因为我是主动的那部分箭头指向相反的方向从我开始，而不是另一端的高飞。恕我直言。

当你发送一个拉取请求时，你是在请求(请求)官方的回购所有者从你自己的回购中拉取一些更改。因此出现了“拉请求”。

“请求”这个词是这些操作的关键。你也可以把它想象成“我有个请求让你接手我的工作，你接受吗?”-“拉请求”。

一开始会有点困惑，但最终会有意义。

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

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

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

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

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

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

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