git push
https://git-scm.com/docs/git-push
使用本地的refs去更新远程的refs。
当<repository>
参数没有指定,
则默认为 branch.*.remote
配置值,
如果没有这个配置,则默认为origin
Updates remote refs using local refs, while sending objects necessary to complete the given refs.
When the command line does not specify where to push with the
<repository>
argument,branch.*.remote
configuration for the current branch is consulted to determine where to push. If the configuration is missing, it defaults to origin.
<refspec>
没有被指定,则参考 remote.*.push
规则
如果没有这个规则, 则 遵循 push.default的
simple规则, 推送到upstream分支。
When the command line does not specify what to push with
<refspec>...
arguments or--all
,--mirror
,--tags
options, the command finds the default<refspec>
by consultingremote.*.push
configuration, and if it is not found, honorspush.default
configuration to decide what to push (See git-config[1] for the meaning ofpush.default
).When neither the command-line nor the configuration specify what to push, the default behavior is used, which corresponds to the
simple
value forpush.default
: the current branch is pushed to the corresponding upstream branch, but as a safety measure, the push is aborted if the upstream branch does not have the same name as the local one.
gitrevisions
https://git-scm.com/docs/gitrevisions
<refname> 分为 heads 和 tags 和 remotes
<refname>, e.g. master, heads/master, refs/heads/master
A symbolic ref name. E.g. master typically means the commit object referenced by refs/heads/master. If you happen to have both heads/master and tags/master, you can explicitly say heads/master to tell Git which one you mean. When ambiguous, a <refname> is disambiguated by taking the first match in the following rules:
If $GIT_DIR/<refname> exists, that is what you mean (this is usually useful only for
HEAD
,FETCH_HEAD
,ORIG_HEAD
,MERGE_HEAD
andCHERRY_PICK_HEAD
);otherwise, refs/<refname> if it exists;
otherwise, refs/tags/<refname> if it exists;
otherwise, refs/heads/<refname> if it exists;
otherwise, refs/remotes/<refname> if it exists;
otherwise, refs/remotes/<refname>/HEAD if it exists.
直接推入库中
git push
git push origin HEAD:refs/heads/master
Gerrit -- refs/for namespace
https://gerrit-review.googlesource.com/Documentation/concept-refs-for-namespace.html
refs/for/[BRANCH_NAME]
此 refs是gerrit专门为了代码走查设立的refs/for子分支。
for表示 for review的意思。
命令 : git push origin HEAD:refs/for/master
When pushing a new or updated commit to Gerrit, you push that commit using a reference, in the
refs/for
namespace. This reference must also define the target branch, such asrefs/for/[BRANCH_NAME]
.For example, to create a new change on the master branch, you would use the following command:
git push origin HEAD:refs/for/masterThe
refs/for/[BRANCH_NAME]
syntax allows Gerrit to differentiate between commits that are pushed for review and commits that are pushed directly into the repository.Gerrit supports using either the full name or the short name for a branch. For instance, this command:
git commit git push origin HEAD:refs/for/masteris the same as:
git commit git push origin HEAD:refs/for/refs/heads/master
Gerrit - refs/changes/
https://gerrit-review.googlesource.com/Documentation/concept-refs-for-namespace.html
对于客户任何的提交, 都对应 refs/for/XXX
实际上服务器端, gerrit存储方式, 将每一个commit都存储到 refs/changes命名空间
Gerrit uses the
refs/for/
prefix to map the concept of "Pushing for Review" to the git protocol. For the git client, it looks like every push goes to the same branch, such asrefs/for/master
. In fact, for each commit pushed to this ref, Gerrit creates a new ref under arefs/changes/
namespace, which Gerrit uses to track these commits. These references use the following format:refs/changes/[CD]/[ABCD]/[EF]Where:
[CD] is the last two digits of the change number
[ABCD] is the change number
[EF] is the patch set number
For example:
refs/changes/20/884120/1You can use the change reference to fetch its corresponding commit:
git fetch https://[GERRIT_SERVER_URL]/[PROJECT] refs/changes/[XX]/[YYYY]/[ZZ] && git checkout FETCH_HEAD
Git Internals - The Refspec
https://git-scm.com/book/en/v2/Git-Internals-The-Refspec
The Refspec
Throughout this book, we’ve used simple mappings from remote branches to local references, but they can be more complex. Suppose you were following along with the last couple sections and had created a small local Git repository, and now wanted to add a remote to it:
$ git remote add origin https://github.com/schacon/simplegit-progit
Running the command above adds a section to your repository’s
.git/config
file, specifying the name of the remote (origin
), the URL of the remote repository, and the refspec to be used for fetching:[remote "origin"] url = https://github.com/schacon/simplegit-progit fetch = +refs/heads/*:refs/remotes/origin/*
gerrit-trigger
https://plugins.jenkins.io/gerrit-trigger/
Specify what type of event(s) to trigger on:
Draft Published: Sent when a change moves from draft state to new. (only available in version 2.5 or higher of Gerrit).
Patchset Created: Sent when a new patchset arrives on a change. Before version 2.6.0, this was the only event you could trigger on.
Change Merged: Sent when a change is merged on the Gerrit server.
Comment Added: Sent when a comment is added to a change. Which category and value to trigger on can be configured. The available categories can be configured in the server settings for the plugin.
Ref Updated: Sent when a ref is updated on the Gerrit server, i.e. someone pushes past code review.
To get the Git Plugin to download your change; set Refspec to $GERRIT_REFSPEC and the Choosing strategy to Gerrit Trigger. This may be under ''Additional Behaviours/Strategy For Choosing What To Build' rather than directly visible as depicted in the screenshot. You may also need to set 'Branches to build' to $GERRIT_BRANCH. If this does not work for you set Refspec to refs/changes/:refs/changes/* and 'Branches to build' to *$GERRIT_REFSPEC.
ℹ️Be aware that $GERRIT_BRANCH and $GERRIT_REFSPEC are not set in the Ref Updated case. If you want to trigger a build, you can set Refspec and 'Branches to build' to $GERRIT_REFNAME.
Refs
https://blog.csdn.net/taiyangdao/article/details/52766424
1)本地分支的Reference格式:refs/heads/<local_branch_name>
如refs/heads/master,在保证唯一的情况下可以简写为master
2)远程追踪分支的Reference格式:refs/remotes/<remote_repository>/<remote_branch_name>
如refs/remotes/origin/master,在保证唯一的情况下可以简写为origin/master
3)tag的Reference格式:refs/tags/<tag_name>
如refs/tags/v1.0.1,在保证唯一的情况下可以简写为v1.0.1