【gerrit】git push origin HEAD:refs/for/xxx的意思

1.git push <remote 名字> <本地分支的名字> : <远程库的名字>

git push origin HEAD:refs/for/xxx
git push 推送
origin : 是远程的库的名字

xxx:就是填你的分支名
HEAD: 是一个特别的指针，它是一个指向你正在工作的本地分支的指针，可以把它当做本地分支的别名，git这样就可以知道你工作在哪个分支

refs/for :意义在于我们提交代码到服务器之后是需要经过code review 之后才能进行merge的
refs/heads 不需要

2.     这个不是git的规则，而是gerrit的规则，

 Branches, remote-tracking branches, and tags等等都是对commite的引用（reference）,引用都以 “refs/……”表示. 比如remote branch: origin/git_int(=refs/remotes/origin/git_int)， local tag: v2.0(=refs/tags/v2.0)， local branch: git_int(=refs/heads/git_int)…

  简单点说，就是refs/for/mybranch需要经过code review之后才可以提交；refs/heads/mybranch不需要code review。

下面一段是对“refs/for”更详细的描述：

The documentation for Gerrit explains that you push to the "magical refs/for/'branch' ref using any Git client tool".

This image is taken from the Intro to Gerrit. When you push to Gerrit, you do git push gerrit HEAD:refs/for/<BRANCH>. This pushes your changes to the staging area (in the diagram, "Pending Changes"). Gerrit doesn't actually have a branch called <BRANCH>; it lies to the git client.

Internally, Gerrit has it's own implementation for the Git and SSH stacks. This allows it to provide the "magical" refs/for/<BRANCH> refs.

When a push request is received to create a ref in one of these namespaces Gerrit performs its own logic to update the database, and then lies to the client about the result of the operation. A successful result causes the client to believe that Gerrit has created the ref, but in reality Gerrit hasn’t created the ref at all.  

After a successful patch (i.e, the patch has been pushed to Gerrit, [putting it into the "Pending Changes" staging area], reviewed, and the review has passed), Gerrit pushes the change from the "Pending Changes" into the "Authoritative Repository", calculating which branch to push it into based on the magic it did when you pushed to refs/for/<BRANCH>. This way, successfully reviewed patches can be pulled directly from the correct branches of the Authoritative Repository.

报错记录

git push 报错：missing Change-Id in commit message footer

使用gerrit后，提交代码会出现如下截图问题：

 

临时解决：

step1:把上面红色的那条gitidir复制下来执行下：

step2:执行下面的命令会添加change_id

　　git commit --amend

step3:然后推送代码到服务器上

　　git push origin HEAD:refs/for/$branch_name

上面这个情况主要针对本地刚下载的仓库，第一次提交会出现这个情况，只需要执行一次，以后再该仓库提交就不用执行了，说白了就是这个commit-msg是局部的，只对当前仓库生效。

还有另外一种情况，也是大家遇到比较多的，就是执行了上面的命令，再push时还是一样的错，这个时候，你就要检查下是否其他提交没有change_id，因为gerrit要求每个提交都要有change_id。

举例：

执行git log 看到类似如下现象：

从上而下，我们用commitid1,commitid2,commitid3表示截图中的三个提交,很明显，第二个提交commitid2没有change_id,这个时候我们可以git reset --soft commitid3来软回退到异常节点的前一个正常的节点，这个操作相当于撤销了最后的git commit -s的操作，add过的代码还在索引库（可以去了解下git reset --soft）,具体操作如下：

(1) git reset --soft commitid3

(2) git status 可以看到绿色的已经add过的文件（即commitid1和commitid2的改动）

(3) git commit -s #添加评论，保存退出后会生成change_id

(4) git log 可以看到已经有了change_id

(5) git push origin HEAD:refs/for/工作分支

我的具体操作如下，供参考：

参考：

https://blog.csdn.net/u012843873/article/details/82424514

该博客中还介绍了第三种方式使用交互式 rebase 找回任意提交位置的 Change-Id ，git rebase -i commitid3,然后参考如下：

其中还介绍了change-ID相关信息，钩子之类的，详细内容见参考链接。