用于合并分支和官方存储库的术语是“拉取请求”。这很令人困惑,因为我似乎是在请求将我的更改推送到官方存储库。

为什么它被称为拉请求而不是推请求?


当前回答

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

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

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

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

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

其他回答

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

消除矛盾。 合并分支。

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

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

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

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