跟随 cmets 到 this answer 和 Gerrit 文档的信息。如果添加正确的 refs 是强制性的：
git push gerrit HEAD:refs/for/master
那为什么 Gerrit 在没有他们的情况下完全接受推动呢？在执行git push origin master 并缺少正确的参考之后，推送被接受（在 Git 级别），但没有创建任何更改（在 Gerrit 级别）。用户最终在代码审查系统中陷入混乱（无法合并不存在的更改，无法推送其他任何内容，因为他或她被 no changes 拒绝）并且必须执行 @987654322 @ 来解决这个问题。
实现某个功能的原因或逻辑是什么，这样的提交会被接受？为什么 Gerrit 不拒绝推送，它根本无法处理？
【问题讨论】：
标签： git version-control gerrit
您可以在 Gerrit 管理页面中创建推送规则，您可以在其中禁用直接推送。查看详情here 在我的团队中，有两个具有不同推送规则的组很有用。在同一个分支上工作的小组，但只有一个小组介绍了 Gerrit 工作流程。但这并不意味着提交或更改会因为以不同的方式推送到远程仓库而导致混乱。 Gerrit/Git 将通过拒绝非快进更改来处理它。
【讨论】：
git checkout -b <branch> origin/master 然后远程：git push origin <branch> 或通过 Gerrit UI。之后一切都会好起来的。
如果用户有足够的权限（特别是涵盖相关引用的 Push 权限，在本例中为 refs/heads/master），她/他可以通过将更改直接推送到分支来绕过审查。这在很大程度上是设计使然，对于导入上游提交等常见任务是必需的。在许多情况下，此操作仅限于管理员、项目维护人员和类似的高级用户以强制执行审查，但我确信有些组织使用 Gerrit 进行可选的代码审查。 Gerrit 应该被视为支持代码审查的通用 Git 服务器。
如果你不想要这种行为，那么你应该调整你的 gits 的访问权限。
【讨论】：