Transfer from Http://lishicongli.blog.163.com/blog/static/146825902013213439500/
1. This is not a git rule, but a Gerrit rule,
2. Branches, remote-tracking Branches, and tags are all references to Commite (reference), and references are expressed as "refs/...". such as 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) ...
3. To put it simply, Refs/for/mybranch needs to pass code review before it can be submitted; refs/heads/mybranch does not need code review.
(since want to directly push into the branch, rather than create code reviews. Pushing to refs/for/* creates code reviews which must is approved and then submitted. Pushing to refs/heads/* bypasses review entirely, and just enters the commits directly into the branch. The latter does not check committer identity, making it appropriate for importing past project history)
If you need code review, direct push
$git Push Origin Master
Then there will be "! [Remote rejected] master-, master (prohibited by Gerrit) "error message
And so push is no problem,
$git Push Origin Head:refs/for/mybranch
The following paragraph is a more detailed description of "Refs/for":
The documentation for Gerrit explains the "Magical refs/for/' branch ' ref using any Git client tool".
This image was 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-create a ref in one of these namespaces Gerrit performs it own logic to update the DAT Abase, and then lies to the client about the result of the operation. A successful result causes the client to believe that Gerrit have created the ref, but in reality Gerrit hasn ' t created the Ref at all.
After a successful patch (i.e, the patch had been pushed to Gerrit, [putting it into the ' Pending changes ' staging area ], reviewed, and the review have passed), Gerrit pushes the change from the "Pending changes" to the "authoritative Repos Itory ", calculating which branch to push it into a based on the magic it does when you pushed to Refs/for/<branch>. This, successfully reviewed patches can is pulled directly from the correct branches of the authoritative repository.< /p>