[Git] 关于refs/for/ 和refs/heads/

本文详细介绍了Gerrit中使用Git推送代码的不同方式及其影响。解释了refs/for/与refs/heads/的区别,前者用于创建代码审查,后者则直接提交到分支。文中还提供了具体的推送命令示例。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 

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

 

关于refs/for/ - Lishic - Theres always a way

 

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/


<think>我们正在分析一个Git命令:`git push origin refs/heads/lvlieyu:master` 这个命令的含义是将本地分支推送到远程仓库的特定分支。 具体分解: - `git push`: Git命令,用于将本地分支的更新推送到远程仓库。 - `origin`: 远程仓库的名称,通常指代最初克隆的仓库(默认远程仓库别名)。 - `refs/heads/lvlieyu:master`: 这是引用规范(refspec),它指定了源分支目标分支。 - `refs/heads/lvlieyu`: 这是本地分支的完整引用路径,表示本地分支名为`lvlieyu`。 - 冒号后面的`master`: 表示远程分支名,即推送到远程仓库的`master`分支。 所以,整个命令的意思是:**将本地的`lvlieyu`分支推送到远程仓库`origin`的`master`分支**。 注意:这种写法与常见的`git push origin lvlieyu:master`效果相同,因为`refs/heads/`是分支引用的标准前缀,通常可以省略。但这里使用了完整引用。 重要提示: 1. 如果远程仓库的`master`分支已经存在,这个操作会尝试用本地的`lvlieyu`分支覆盖远程的`master`分支。 2. 如果远程仓库的`master`分支是受保护的(比如有分支保护规则),可能需要强制推送(使用`--force`或`--force-with-lease`),但强制推送要谨慎使用。 示例流程: - 假设当前在本地`lvlieyu`分支上工作,执行这个命令后,远程`master`分支将本地`lvlieyu`分支保持一致。 另外,如果希望将本地分支推送到远程仓库并建立跟踪关系,通常的做法是: `git push -u origin lvlieyu:master` (-u 选项用于设置上游分支) 但是,这个命令并没有使用`-u`,所以只是推送,不会建立跟踪关系。 总结:该命令用于将本地分支(lvlieyu)推送到远程仓库(origin)的master分支,可能用于覆盖远程master分支的内容。 §§相关问题§§ 1. 如果远程仓库的master分支有新的提交,而本地lvlieyu分支是基于旧版本开发的,执行此命令会有什么后果? 2. 如何避免使用强制推送(force push)来覆盖远程分支? 3. 在Git中,refs/heads/前缀的作用是什么?为什么有时候需要显式指定? 4. 除了分支,Gitrefspec还可以用于推送哪些类型的引用? 5. 如果希望将本地分支推送到远程仓库并同时建立跟踪关系(tracking),应该如何在命令中添加参数?</think>### Git命令解析:`git push origin refs/heads/lvlieyu:master` #### 命令结构分解: | 部分 | 含义 | |------|------| | `git push` | Git推送命令 | | `origin` | 远程仓库别名(默认远程仓库名称) | | `refs/heads/lvlieyu:master` | **引用规范(refspec)** | #### 核心含义: **将本地分支 `lvlieyu` 强制推送到远程仓库的 `master` 分支** (相当于:`git push origin lvlieyu:master`) --- ### 关键细节说明: 1. **引用规范(refspec)结构** ```bash <本地分支>:<远程分支> # 本示例中: # 本地分支 = refs/heads/lvlieyu (lvlieyu分支) # 远程分支 = master ``` 2. **特殊行为**: - ⚠️ **覆盖式推送**:会**强制覆盖**远程仓库的 `master` 分支 - ⚠️ **无安全校验**:不检查远程分支是否有更新(类似 `--force` 效果) - 🔄 **分支映射**:本地 `lvlieyu` 分支内容将完全替换远程 `master` 分支 3. **与常规推送的区别**: ```bash # 常规安全推送(会检查冲突) git push origin master # 本命令效果(强制覆盖) git push origin lvlieyu:master --force ``` --- ### 典型使用场景: 1. **紧急修复覆盖** 当远程 `master` 分支被意外破坏时,用本地验证过的分支覆盖 2. **分支重定向** 将已废弃的分支内容迁移到主分支(需团队协调) 3. **仓库维护操作** 在Git托管平台执行分支重构时使用 --- ### 风险警告(需谨慎操作): 1. **数据丢失风险** 远程 `master` 分支的所有历史提交将被覆盖 2. **团队协作问题** 可能导致其他开发者基于旧版本继续开发 3. **恢复难度** 被覆盖的分支只能通过 `reflog` 或备份恢复 ```mermaid graph LR A[本地 lvlieyu 分支] -- 强制推送 --> B(远程 master 分支) C[远程原有内容] -- 被完全覆盖 --> D[丢失历史记录] ``` --- ### 安全替代方案: ```bash # 1. 先创建备份分支 git push origin master:master_backup # 2. 使用安全推送(检查冲突) git push origin lvlieyu:master # 3. 若必须强制推送,添加警告标记 git push origin lvlieyu:master --force-with-lease ```
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值