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

我刚刚开始使用gerrit，我想知道为什么我们需要做

git-push-gerrit-HEAD:refs/for/master

而不是做

git-push-origin-master

---

如果我做了

git推原始主机

，我得到的错误是

！[remote rejected]master->master（Gerrit禁止）

Gerrit的文档，特别是该部分，解释了您使用任何Git客户端工具推送到“magic

refs/for/'branch'

ref”

下面的图像取自。当你推到Gerrit时，你会推Gerrit HEAD:refs/for/。这会将您的更改推送到暂存区域（在图中为“挂起的更改”）。Gerrit实际上没有一个名为

的分支；这取决于git客户端

在内部，Gerrit为Git和SSH堆栈提供了自己的实现。这允许它提供“神奇的”

refs/for/

refs

当接收到在其中一个名称空间中创建ref的推送请求时，Gerrit执行自己的逻辑来更新数据库，然后向客户机谎报操作结果。成功的结果使客户相信Gerrit创建了ref，但实际上Gerrit根本没有创建ref。[].

---

成功的修补程序（即，修补程序已推送到Gerrit，[将其放入“待定更改”暂存区]、已审核且审核通过）后，Gerrit将更改从“待定更改”推送到“权威存储库”，根据推送到

refs/for/

时的魔力计算要推送到哪个分支。通过这种方式，可以直接从

权威存储库的正确分支中提取成功审查的修补程序
 为了避免完全指定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

这是根据
出于好奇，如果只执行“git push origin”之类的操作，会发生什么？我试过了，但在任何地方都看不到变化，因此问题就来了。当然，它确实存在于我的本地日志中。@Pintolaranja我不小心也这样做了。你说得对，Gerrit“处理”了这样的情况，但它不会带来任何变化。所以实际上，它根本不能处理它。这真的让我很生气，因为这太愚蠢了。为什么要允许用户提交Gerrit无法正确处理的内容？@gregb Yes。箭头指示命令的源和目标，而不是由此产生的任何后续数据流。e、 g.Developer 1向权威存储库发出获取，而不是以其他方式around@trejder它允许这样做，因为Gerrit允许您配置一些帐户以绕过审核。通过推到默认分支，实际上是在说“我想合并此更改而不进行审阅”。如果不允许这样做，推送将失败。事实上，如果git/gerrit互操作已经正确构建，您就不必这么愚蠢，只需执行“git推送源代码”（更好的是，只执行“git推送”）然后，git/gerrit将以这样一种方式进行配置，即它将自动将您的更改放置在一个暂存区域中，以供代码审查。强迫你去一个不同的地方，而不是你想要改变的地方，这是愚蠢的，会增加混乱，这会导致错误。+1来自我！为我的
remote.origin.push
硬编码比每次都要键入/粘贴要好得多@SeanMurphy您可以将“master”的实例替换为“*”，这样“git push gerrit TopicBranch”之类的东西也可以工作，从而使它更通用。此外，如果gerrit是您唯一的遥控器，则根本不必指定它。我只需使用上面提到的配置@DavidDoria执行
git fetch
和
git push
。push=refs/heads/*：refs/for/*适用于所有分支您确实需要使用上游分支，而不是当前分支。我通常有十几个左右的变化并行进行，所以使用一个分支根本不起作用。虽然有一些答案，但这就像“对客户撒谎”和“神奇”。这就是我不喜欢当前软件工程状态的原因：工作中没有人真正知道发生了什么，推送实际上给出了一个
致命的：内部服务器错误
，但同时还有一个
remote:SUCCESS
的打印输出，这似乎是相互矛盾的消息，有时Gerrit启动的测试是有效的，有时没有，没有任何改变。没有人知道发生了什么的感觉是不好的