用于合并分支和官方存储库的术语是“拉取请求”。这很令人困惑,因为我似乎是在请求将我的更改推送到官方存储库。
为什么它被称为拉请求而不是推请求?
用于合并分支和官方存储库的术语是“拉取请求”。这很令人困惑,因为我似乎是在请求将我的更改推送到官方存储库。
为什么它被称为拉请求而不是推请求?
如果您在存储库中有一个代码更改,并希望将其移动到目标存储库,那么:
“Push”是你强制目标存储库中出现的更改(git Push)。 “Pull”是目标存储库抓取你的更改,以呈现在那里(git从另一个repo拉)。
“拉取请求”是您请求目标存储库获取您的更改。
“推送请求”将是目标存储库请求您推送更改。
既然我不被允许出手,我就很好地向回购所有者提出请求,让他们决定退出
谁可以将代码推送到存储库?
如果有人(可能是邪恶的、没受过教育的或未知的)能够来这里说,我刚刚把这个推到你的主分支,搞砸了你所有的代码,哈哈哈!?
你肯定不希望他那样做吧。默认情况下设置了一个安全网,所以没有人可以推动你的回购。你可以把其他人设置为合作者,然后他们可以推动。你会把这样的机会给你信任的人。
所以如果你不是一个合作者,尝试推送,你会得到一些错误,表明你没有权限。
那么,其他开发商如何推动他们没有获得许可的回购呢? 你不能给每个人访问权限,但你想给其他人一个出口/入口点,这样他们就可以“向回购所有者请求将此代码拉入回购”。简单地说,通过使回购可访问,他们可以分叉…在自己的fork中进行更改。将他们的更改推到他们自己的fork上。一旦它在他们自己的远程回购:
他们从他们的分叉发出一个拉取请求,上游回购的所有者(你不能直接推到)将决定是否合并拉取请求。
换个角度解释一下:
推送是指你(通常)不需要任何人批准的事情,例如,你总是可以推送到你自己创建并一直致力于的功能分支。
虽然您可以在您自己创建的两个分支之间创建一个拉请求,并可以将其推入。你几乎从不这样做。
当我致力于一个大型功能并且已经批准了我的pull请求时,我便这么做了,但我需要做出一些棘手的改变,所以我便针对我现有的分支创建了PR。
如果你需要别人的认可,那你就不要强迫别人。你希望别人:
回顾你的分支 给你批准 去拿你的树枝 与master合并
(3+4 = git pull)
顺便说一句,你可能会问,为什么它不被命名为“合并请求”?
我发现最好的答案是,如果你只是直接提交到main -没有多个功能分支,那么你永远不会有merge(两个父组成一个子)提交。所有的提交都是对前一个提交的新提交。因此,名称“合并提交”将不适用。
还有一个半相关的问题,我推荐阅读git推送到底发生了什么?为什么git push不像git merge那样被考虑?
我想把一些东西推到别人的回购中。
我没有推(或拉)的权限。
所有者/合作者拥有权限。它们既能推又能拉。我推不动。
所以,我要求他们执行我的拉——这间接地意味着我要求他们接受我的推。
所以,没有推送请求。只是为了拉一把。并接受一个推动。
因此,这是一个“pull”请求。而不是“push”请求。
我认为这是一个愚蠢的术语,因为我想认为我想把一些东西推给你,而不是反过来要求别人拉我的添加。所以应该改为PUSH REQ。因为我是主动的那部分箭头指向相反的方向从我开始,而不是另一端的高飞。恕我直言。
这样思考。本地存储库vs远程存储库。
当你从本地推送。(git push) -换句话说,远程存储库正在从您(本地)拉代码。
你在提出要求。所以,问问你自己,
你想要远程存储库从你拉代码吗?-拉请求。
为了更好地理解它并永远记住它,你需要描绘它。
想象一个大的、活的树(作为您的存储库)。这棵树太坚固了,你不能将一个分支推入或添加一个新部分(象征创建一个新分支或你将代码推入其中),相反,你必须要求这棵树将一个分支拉入主干或从你那里获得更改。
术语“拉请求”来自于分布式的本质。而不是仅仅将您的更改推入存储库(就像您使用集中式存储库所做的那样,例如Subversion),您将单独发布您的更改,并要求维护者拉入您的更改。然后维护者可以查看更改并执行所谓的拉取。
所以你基本上是“请求”那些对你想要贡献的回购有写权限的人,从你的回购中“拉”出来。
Pull请求可以让你告诉其他人你已经推送到GitHub存储库分支的更改。一旦打开了拉取请求,您就可以与协作者讨论和检查潜在的更改,并在将更改合并到基本分支之前添加后续提交。 Github的解释
恐怕大多数答案都回答了“pull request”是什么意思?“push request”是什么意思?而不是OP的问题:为什么它被称为拉请求而不是推请求?
通常这种问题替换是可以接受的,但在这种情况下,OP显然知道这些替换问题的答案,所以回答它们并不是很有帮助。
只有在GitHub创造了这个词的人知道确切的答案。然而,似乎很明显,这个术语选择反映了类似以下关于“从外部进入存储库的更改”现象的观点:维护者执行操作(拉)。
然而,请求也是一个动作,动作的执行者不是维护者,而是提交者(他做了更多的动作,即工作)。因此,术语“拉请求”造成了关于代理是谁的混乱。最终产生混淆的原因是请求的递归性质:请求既是主代理的操作,也是第二个代理对未来操作的请求。
这种情况非常类似于现在常见的语言结构,如“我们建造了我们的房子”(用来代替“我们付钱给别人建造我们的房子”),因为主要行动的责任从明显的原始代理转移到履行管理社会角色的次要代理。
人们可以由此得出结论,选择术语的原因是使“管理工作是一流劳动”这一观点合法化。此外,对这一术语选择感到困惑的原因可能是,非管理者的员工自然有不同的观点。
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
好的。现在,您必须再次将新的提交拉到您的回购并发出新的推送请求。别忘了,可能会有一些新的代码提交给上游……理论上你可能要一直循环下去。
根据经验,你可能最终会做出一个没有冲突的出色的推送请求。恭喜你,但是有成百上千的推送请求。如果用户首先接受了另一个推送请求,则必须再次进行拉推操作。
因此,要使一个贡献工作整齐,所请求的操作必须有两部分:
消除矛盾。 合并分支。
而且必须由主人来做。否则,所有人必须:
批准贡献者的新代码。 认可贡献者消除冲突的方式。
但是就像这个例子一样,当贡献者消除冲突时,可能会引入更多的冲突。
所以,拉拔操作自然是选择。这就是为什么只有拉请求而没有推请求。
任何需要一段解释的术语,都表明术语的选择不是直观的,具有复杂性或片面性。上面有很多写得很好的解释,所以我就不再赘述了,但这里是我对git中的push和pull术语感到沮丧的评论。
考虑门上正常的“推”和“拉”标签。
它是从即将开门的人的眼睛里解读出来的。
如果是“推”,这个人就会“推”。
如果它说“拉”,自然会有一个把手,用来把门拉向自己。
现在想象一下,如果gitHub制造了门,并在门上写了“拉”,只是为了让门从另一端被拉,而不是从你的一端被拉(所以在某种程度上,这是正常世界中的推!)。然后,你会用你的大脑来对抗直觉思维,并将拉门转化为推门。
正是这种想法导致了这种混乱。
我们大脑中依赖直觉和原始解释的系统会进入一个冲突区。
我只是选择接受git Pull和Push请求的这个异常定义,并将其作为生活中一旦遇到的许多例外之一,然后继续前进。