为什么是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) ! [remote rejected] master -> master (prohibited by Gerrit)
Gerrit的文档，特别是“推送更改”部分解释说，您使用任何Git客户端工具推送到“神奇的refs/for/'branch' ref。
下面的图片是从Intro到Gerrit的 。 当你推到Gerrit，你做git push gerrit HEAD:refs/for/<BRANCH> 。 这会将您的更改推送到暂存区域 （图中的“待定更改”）。 Gerrit实际上并没有一个名为<BRANCH>的分支; 它在于git客户端。
在内部，Gerrit有自己的Git和SSH堆栈实现。 这使得它可以提供“神奇的” refs/for/<BRANCH> refs。
当收到一个推送请求在其中一个命名空间中创build一个ref时，Gerrit执行自己的逻辑来更新数据库，然后对客户说谎操作的结果。 一个成功的结果让客户相信Gerrit已经创build了ref，但实际上Gerrit并没有创buildref。 [ 链接 – Gerrit，“坚韧细节” ]。
在一个成功的补丁（也就是补丁已经被推送到Gerrit，将其放到“待定变更”中间区域中），审核通过后，Gerrit推动了从“Pending Changes”到“权威版本库“，根据它推送到refs/for/<BRANCH>时所执行的魔法计算将哪个分支推送到它。 这样，成功审查的补丁可以直接从Authoritative Repository的正确分支中提取。
为了避免完全指定git push命令，你可以修改你的gitconfiguration文件：
[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
这是根据Gerrit
