git/refs/ . In Git, a head is a ref that points to the tip (latest commit) of a branch. You can view your repository's heads in the path . git/refs/heads/ . In this path you will find one file for each branch, and the content in each file will be the commit ID of the tip (most recent commit) of that branch.
git branch. should show all the local branches of your repo. The starred branch is your current branch. To retrieve only the name of the branch you are on: git rev-parse --abbrev-ref HEAD. or with Git 2.22 and above: git branch --show-current.
When a repository has hundreds or thousands of tags, this one-file-per-ref format both wastes storage and hurts performance. This command is used to solve the storage and performance problem by storing the refs in a single file, $GIT_DIR/packed-refs .
origin/HEAD represents the default branch on the remote, i.e. the HEAD that's in that remote repository you're calling origin.
A ref
is anything pointing to a commit, for example, branches (heads), tags, and remote branches. You should see heads, remotes, and tags in your .git/refs
directory, assuming you have all three types of refs in your repository.
refs/heads/0.58
specifies a branch named 0.58. If you don't specify what namespace the ref is in, git will look in the default ones. This makes using only 0.58 conceivably ambiguous - you could have both a branch and a tag named 0.58.
Just for somebody who is curious - git show-ref
, which is available since Git v1.8.2.2, will show you all references you have in your local repository.
See, branchName
needs to be fully resolved before GIT can actually identify it. The fully resolved name will be refs/heads/branchName
.
One of the famous commandsgit checkout branchName
actually automatically resolves it fully to identify where you want to checkout. Note that it does it automatically hence we never write it fully on our own.
How does it do that ? Let us look here
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 bothheads/master
andtags/master
, you can explicitly sayheads/master
to tell Git which one you mean. When ambiguous, a<refname>
is disambiguated by taking the first match in the following rules:1.If
$GIT_DIR/<refname>
exists, that is what you mean (this is usually useful only forHEAD
,FETCH_HEAD
,ORIG_HEAD
,MERGE_HEAD
andCHERRY_PICK_HEAD
);2.otherwise,
refs/<refname>
if it exists;3.otherwise,
refs/tags/<refname>
if it exists;4.otherwise,
refs/heads/<refname>
if it exists;5.otherwise,
refs/remotes/<refname>
if it exists;6.otherwise,
refs/remotes/<refname>/HEAD
if it exists.
So by above 6 steps , it tries to resolve what is this branchName
. Hence we never need to give a fully resolved branchName to it.
Look here and here too.
Also, go in your .git
directory and see inside the ref
folder.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With