【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.