我正在关注我们IT部门的一个例子，我想了解这个命令究竟在做什么：
git fetch origin +refs/changes/*:refs/remotes/origin/changes/*
为了给出一些参考框架，这是持续集成（CI）工具的一部分，这是检查要测试的代码的步骤的一部分。通过向Gerrit推送CI来触发CI构建：
git push origin HEAD:refs/for/master
我的第二个问题是，如果我想将更改推送到开发分支，我可以使用：
git push origin HEAD:refs/for/development
答案 0 :(得分：0)
我对gerrit一无所知。但我可以说一下你提到的第一个git命令。
您提到的命令的最后部分称为refspecs。您可以在Refspec chapter of the Pro Git book中了解他们的行为。简而言之：
git fetch origin +refs/changes/*:refs/remotes/origin/changes/*
这表示，对于origin远程，获取分支的提交，这些分支在origin存储库中位于git目录中的refs/changes目录中（即{{ 1}}在标准存储库中，.git/refs/changes/在普通的裸存储库中）。它会将这些分支复制到本地目录refs/changes。最后，按照正常的提取行为，它会将属于这些分支的提交复制到.git/refs/remotes/origin/changes/目录。
标准refspec是.git/object所以+refs/heads/*:refs/remotes/origin/*对我来说有点奇怪。那不是标准的Git目录，但也许它是Gerrit的东西。结构refs/changes看起来像refs/remotes/origin/changes是本地存储库中的一个分支。
答案 1 :(得分：0)
补丁的典型拉力如下所示：
git pull ssh://www.example/com:29418/project refs/changes/24/24/2
这将拉动你的项目加上第二个补丁变更集24.所以当你拉出所有可能很多的变化时。
我建议您使用Jenkins（CI）和Gerrit插件，并确保将choosing strategy指定为Gerrit Trigger。这将确保您构建将测试适当的更改集。
是的，您可以推送到开发分支。当然，您需要确保拥有正确的权利。最好是首先在Gerrit中创建分支，这样你就不必给出“创建引用”权限，并且例如通过拼写错误防止错误地创建分支。