[Git] 关于refs/for/ 和refs/heads/
2015-10-12 10:17
309 查看
转自http://lishicongli.blog.163.com/blog/static/146825902013213439500/
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".
![](http://img0.ph.126.net/ihGEy9LCvLvCpNV1Yp8jQQ==/6598167079261567773.png)
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.
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".
![](http://img0.ph.126.net/ihGEy9LCvLvCpNV1Yp8jQQ==/6598167079261567773.png)
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.
相关文章推荐
- linux文件操作常用命令
- ASP.Net MVC(3)
- ios隐藏顶部状态和修改顶部状态栏字体颜色
- linux学习札记
- UVA-12545 Bits Equalizer (贪心)
- 动态规划[入门]2-循环数组最大子段和
- 12家人均创收最高的科技公司
- 9月全球操作系统版本份额:Win 10第四 涨势喜人
- JAVA中的四种引用:强引用,软引用,弱引用,虚引用
- Multiply Strings 大数相乘 java
- Java基础知识强化之IO流笔记55:IO流练习之 自定义类模拟LineNumberReader的获取行号功能案例
- lintcode:数飞机
- 华为机试:过滤重复单词
- UIView的最常用知识
- 习题二
- Lucene(5.3.1) demo
- 四、从数字中发现规律?
- 360HBase二级索引方案学习总结
- git 创建分支并切换
- 白石老人