为什么使用git push gerrit HEAD：refs / for / master代替git push origin master

148

我刚刚开始使用Gerrit，我想知道为什么我们需要做git push gerrit HEAD:refs/for/master而不是做git push origin master

如果我这样做，git push origin master我会收到错误提示! [remote rejected] master -> master (prohibited by Gerrit)

git gerrit

— Shrayas
source

Answers:

259

Gerrit的文档，特别是“ Push changes”部分，说明您将推送至“ refs/for/'branch'使用任何Git客户端工具的魔术引用”。

下图是从Gerrit简介拍摄的。当您选择Gerrit时，您会这样做git push gerrit HEAD:refs/for/<BRANCH>。这会将您的更改推送到登台区域（在图中，“待更改”）。Gerrit实际上没有一个名为的分支<BRANCH>。它在于git客户端。

在内部，Gerrit对Git和SSH堆栈具有自己的实现。这使其可以提供“魔术” refs/for/<BRANCH>参考。

当收到在这些名称空间之一中创建引用的推式请求时，Gerrit会执行其自己的逻辑来更新数据库，然后向客户端介绍操作结果。成功的结果使客户相信Gerrit已创建引用，但实际上Gerrit根本没有创建引用。[ 链接-Gerrit，“ Gritty详细信息” ]。

Gerrit工作流程

成功修补程序后（即，修补程序已推送到Gerrit，[将其放入“待更改”暂存区”，进行了审核，并且审核已通过），Gerrit将更改从“待更改”推送到了“权威存储库”，根据您推送到时的魔术来计算将其推送到哪个分支refs/for/<BRANCH>。这样，可以将已成功查看的补丁直接从的正确分支中提取Authoritative Repository。

— 西蒙
source

出于好奇，如果仅执行“ git push origin”之类的事情会发生什么？我尝试过，却看不到任何变化，因此是问题所在。但是它自然存在于我的本地日志中。

@Pintolaranja我偶然地做了同样的事情。没错，Gerrit可以“处理”这种情况，但不会造成任何变化。所以实际上，它根本无法处理它。这真的让我生气，因为这真是愚蠢。为什么允许用户提交Gerrit无法正确处理的某些内容？

— trejder 2013年

@gregb是的。箭头指示命令的源和目的地，而不是由此产生的任何后续数据流。例如，开发人员1向授权存储库发出访存请求，而不是相反

— Gareth 2014年

@trejder它允许这样做，因为Gerrit允许您配置一些帐户以绕过评论。通过推送到默认分支，您实际上是在说“我想合并此更改而不进行审查”。如果不允许这样做，则推送失败。

— Hounshell 2015年

或者，您不能使用Gerrit并完全避免这种滑稽的混乱。

— C约翰逊

为了避免完全指定git push命令，您可以选择修改git config文件：

[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

据格里特说

— 肖恩·墨菲
source

向我+1！只需为我进行硬编码，remote.origin.push而不是每次都要键入/粘贴它，就会更好！

— 道文

@SeanMurphy您可以通过将'master'的实例替换为'*'来使其更通用，以便像'git push gerrit TopicBranch'之类的东西也可以使用。

— 大卫·多里亚

另外，如果gerrit是您唯一的遥控器，则完全不必指定它。我简单地做git fetch，并git push与配置@DavidDoria如上所述。

— 伯恩克

推=裁判/头/ *：裁判/为/ *对所有分支机构

— 维克托蔡

您确实需要使用上游分支，而不是当前分支。我通常会并行进行十几个更改，因此使用单个分支是行不通的。

— Christian Goetze