博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
关于refs/for/ 和refs/heads/
阅读量:7030 次
发布时间:2019-06-28

本文共 2319 字,大约阅读时间需要 7 分钟。

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.

 

转载自: 

转载于:https://www.cnblogs.com/onelikeone/p/6857932.html

你可能感兴趣的文章
typescript文档化工具——Typedoc
查看>>
JS数据结构0x004:链表
查看>>
以太坊钱包开发系列1 - 创建钱包账号
查看>>
社交系统 ThinkSNS+ V2.1.1 更新播报
查看>>
理解CPU分支预测,提高代码效率
查看>>
javascript调试接口
查看>>
Python基础系列:初识python引用计数与弱引用
查看>>
javascript继承方法以及优缺点
查看>>
tab 切换下划线跟随实现
查看>>
20+个很棒的Android开源项目
查看>>
跨域、vue双向绑定相关面试题
查看>>
Web Components(一)入门
查看>>
mpvue打包没有app.json等配置文件的解决方法
查看>>
树莓派配置swoole环境
查看>>
JavaScript 工作原理之十二-网络层探秘及如何提高其性能和安全性
查看>>
搭建基于react项目的心得
查看>>
react-native踩坑记录
查看>>
HTTP API 设计入坑指南(一)
查看>>
OkHttp源码分析
查看>>
【挖坑系列】跨域问题相关
查看>>