关于refs/for 和 refs/heads:

1.     这个不是git的规则,而是gerrit的规则,

2.     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)…

3.     简单点说,就是refs/for/mybranch需要经过code review之后才可以提交;refs/heads/mybranch不需要code review

(since you want to directly push into the branch, rather than create code reviews. Pushing to refs/for/* creates code reviews which must be 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)

如果需要code review,直接push

$ git push origin master

那么就会有“! [remote rejected] master -> master (prohibited by Gerrit)”的错误信息!

而这样push就没有问题:

$git push origin HEAD:refs/for/mybranch

下面一段是对“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.

转载自: http://lishicongli.blog.163.com/blog/static/146825902013213439500/

最新文章

  1. 如何编写Iveely搜索引擎插件
  2. [ActionScript 3.0] Away3D 灯光的使用
  3. Hapoop原理及MapReduce原理分析
  4. House Robber——LeetCode
  5. 转:Qt 嵌入式开发环境搭建
  6. HTML通过事件传递参数到js 二 event
  7. 跨DB Server创建View
  8. HashMap代码解析
  9. Docker配置参考
  10. rpm 打包的时候 不进行strip
  11. 基于FeignClient提供简单的用户查询服务
  12. openssl实现CA自签证书和颁发数字证书
  13. [No0000138]软件开发基础知识
  14. js中常用的offset client screen对象
  15. 转载:删除github上文件夹的两种方式
  16. ElasticSearch概述
  17. linux mysql 卸载与安装及配置命令
  18. 【jsp】jsp中的动作元素
  19. vee-validate 中文配置报错及自定义规则 报错.updateDictionary/.addlocale is not a function
  20. Nginx之虚拟目录-root与alias的区别

热门文章

  1. 并发新特性—Executor 框架与线程池
  2. matplotlib plot 绘图函数发生阻塞(block)时的解决方法
  3. angularjs1.6 制作流程图,启动流程,流程设置
  4. 手动安装huson插件的做法
  5. 已解决!Fatal error compiling: 无效的标记(maven启动失败)
  6. Service熟人
  7. 关于生命周期里执行setState
  8. Hibernate——(5)持久化对象和一级缓存机制
  9. spring-boot-starter-parent 1.3.6.RELEASE
  10. Cordova 集成极光推送