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

本文解释了Gerrit中refs/for与refs/heads的区别,如何通过`git push origin HEAD:refs/for/mybranch`进行代码审查,并介绍了提交流程和身份验证规则。阅读者将理解如何在Gerrit中正确提交以触发审查。
摘要由CSDN通过智能技术生成

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/0616--ataozhijia/p/4165052.html

### 回答1: 这个错误提示通常表示你正在尝试向 Git 服务器的主分支(master分支)推送更改,但是 Git 服务器上的钩子(hook)拒绝了推送操作。这可能是由于多种原因引起的,最常见的原因是你试图将不兼容的更改推送到远程主分支上。 解决此问题的最佳方法是首先确保你的本地分支是与远程主分支同步的。可以使用以下命令获取最新的远程变更: ``` git fetch origin ``` 然后,将本地分支与远程分支进行合并: ``` git merge origin/master ``` 如果本地分支有冲突,需要解决冲突并提交更改。然后再次尝试推送: ``` git push origin master ``` 如果问题仍然存在,可能需要检查 Git 服务器上的钩子以查找其他问题。 ### 回答2: 当使用`git http push`命令时,如果出现`refs/heads/master:refs/heads/master [remote rejected] (pre-receive hook declined)`的错误提示,通常是由于服务器端的`pre-receive hook`脚本拒绝了推送操作导致的。 在Git中,`pre-receive hook`是服务器端的一个钩子脚本,用于在接收到推送操作之前执行一些检查和验证。这个脚本可以被用来限制某些不允许的操作,例如禁止强制推送或者限制特定分支的修改权限。 导致出现该错误的原因可能有以下几种: 1. 权限不足:服务器可能已经配置了`pre-receive hook`脚本,用于验证用户的权限或限制特定操作。如果你没有足够的权限执行推送操作,就会出现该错误。 2. 推送的分支被锁定:服务器端可能配置了锁定某些分支的操作,防止不必要的修改。如果你试图推送被锁定的分支,就会出现该错误。 3. 钩子脚本的逻辑检查不通过:`pre-receive hook`脚本可能包含了一些自定义逻辑检查,用于验证推送操作的合法性。如果你的推送操作不满足这些逻辑检查的条件,就会出现该错误。 要解决该问题,你可以尝试以下几个步骤: 1. 检查你的权限:确认你有足够的权限进行推送操作,如果没有,请联系服务器管理员或拥有足够权限的人员。 2. 检查分支锁定:确认你试图推送的分支没有被锁定,如果有,在解锁之前无法进行推送操作。 3. 检查钩子脚本:检查服务器端的`pre-receive hook`脚本,了解其中包含的逻辑检查和验证规则。确保你的推送操作满足这些规则,否则需要进行相应的修改。 总之,该错误提示提示了推送操作被服务器端的`pre-receive hook`脚本拒绝。通过检查权限、分支锁定和钩子脚本等方面,可以解决这个问题。 ### 回答3: 当在git中使用HTTP协议进行push操作时,可能会出现以下错误提示:"refs/heads/master:refs/heads/master [remote rejected] (pre-receive hook declined)"。这个错误提示通常是由于pre-receive hook拒绝了push操作导致的。 Pre-receive hook是一个在git服务器上运行的脚本,用于在push操作之前执行一些自定义的验证或审查操作。这些操作可能包括检查提交的代码是否符合公司的代码规范、验证用户的权限等。 当出现上述错误时,说明你所执行的push操作被pre-receive hook拒绝了。这可能是由于以下一些原因导致的: 1. 代码规范不符:pre-receive hook可能会检查提交的代码是否符合特定的代码规范。如果你的提交代码不符合这些规范,就会导致push操作被拒绝。 2. 权限不足:pre-receive hook还可以用来验证用户的权限,以确保只有授权用户能够进行push操作。如果你的权限不足,就会导致push操作被拒绝。 解决这个问题的方法是根据具体的原因进行相应的调整和修复。如果是代码规范问题,你需要检查自己的代码是否符合要求,并进行相应的修改。如果是权限问题,你需要联系相应的管理员,获取足够的权限来执行push操作。 最后,如果你无法解决这个问题,你可以尝试使用其他协议(如SSH)来进行push操作,或者与git服务器的管理员联系,寻求进一步的帮助和指导。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值