为什么git push gerrit HEAD:refs/for/master使用而不是git push origin master
我刚开始使用gerrit,我想知道为什么我们需要做git push gerrit HEAD:refs/for/master而不是做git push origin master
如果我这样做,git push origin master我会收到错误说! [remote rejected] master -> master (prohibited by Gerrit)
sim*_*ont 247
Gerrit的文档,特别是"推送更改"部分,解释了您refs/for/'branch'使用任何Git客户端工具推送到"神奇的参考".
以下图片取自Gerrit的简介.当你推向Gerrit时,你会这样做git push gerrit HEAD:refs/for/<BRANCH>.这会将您的更改推送到暂存区域(在图表中,"待更改").Gerrit实际上并没有一个叫做分支的分支<BRANCH>; 它取决于git客户端.
在内部,Gerrit有自己的Git和SSH堆栈实现.这允许它提供"神奇"的refs/for/<BRANCH>参考.
当收到推送请求以在其中一个命名空间中创建ref时,Gerrit会执行自己的逻辑来更新数据库,然后向客户端提供有关操作结果的信息.一个成功的结果导致客户认为Gerrit已经创建了ref,但实际上Gerrit根本没有创建ref.[ Link - Gerrit,"Gritty Details" ].
在成功修补程序(即修补程序已被推送到Gerrit,[将其置于"待更改"暂存区域],审核并且审核已通过)之后,Gerrit将此更改从"待处理更改"推送到"权威知识库",根据你推送时所做的魔术来计算推进它的分支refs/for/<BRANCH>.这样,成功审查的补丁可以直接从正确的分支中提取Authoritative Repository.
- 这是一个美丽的回复.谢谢 :) (8认同)
- @trejder它允许这样做,因为Gerrit允许您配置一些帐户以绕过评论.通过推送到默认分支,您实际上是在说"我想在没有审核的情况下合并此更改".如果您不允许这样做,则推送失败. (5认同)
- @Pintolaranja 我无意中也做了同样的事。你是对的，Gerrit“处理”了这种情况，但它并没有带来任何改变。所以实际上，它根本不处理它。这真的让我很生气，因为这真的很愚蠢。为什么要允许用户提交一些 Gerrit 无法正确处理的内容？ (2认同)
- @gregb 是的。箭头指示命令的来源和目的地，而不是任何后续的数据流。例如，开发人员 1 向权威存储库发出 fetch，而不是相反 (2认同)
Sea*_*phy 57
为了避免必须完全指定git push命令,您可以选择修改您的git配置文件:
[remote "gerrit"]
url = https://your.gerrit.repo:44444/repo
fetch = +refs/heads/master:refs/remotes/origin/master
push = refs/heads/master:refs/for/master
现在你可以简单地说:
git fetch gerrit
git push gerrit
根据格里特的说法
- @SeanMurphy你可以通过用'*'替换'master'的实例来使它更通用,这样像'git push gerrit TopicBranch'这样的东西也可以工作. (7认同)