A revision parameter <rev> typically, but not necessarily, names a commit object. It uses what is called
an extendedSHA-1 syntax. Here are various ways to spell object names. The ones listed near the end of
this list name trees and blobs contained in a commit.
Note
This document shows the "raw" syntax as seen by git. The shell and other UIs might require additional
quoting to protect special characters and to avoid word splitting.
<sha1>, e.g. dae86e1950b1277e545cee180551750029cfe735, dae86e
The full SHA-1 object name (40-byte hexadecimal string), or a leading substring that is unique within
the repository. E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both name the same commit
object if there is no other object in your repository whose object name starts with dae86e.
<describeOutput>, e.g. v1.7.4.2-679-g3bee7fb
Output from gitdescribe; i.e. a closest tag, optionally followed by a dash and a number of commits,
followed by a dash, a g, and an abbreviated object name.
<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:
1. If $GIT_DIR/<refname> exists, that is what you mean (this is usually useful only for HEAD,
FETCH_HEAD, ORIG_HEAD, MERGE_HEAD, REBASE_HEAD, REVERT_HEAD, CHERRY_PICK_HEAD, BISECT_HEAD and
AUTO_MERGE);
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.
HEAD
names the commit on which you based the changes in the working tree.
FETCH_HEAD
records the branch which you fetched from a remote repository with your last gitfetch
invocation.
ORIG_HEAD
is created by commands that move your HEAD in a drastic way (gitam, gitmerge, gitrebase, gitreset), to record the position of the HEAD before their operation, so that you can easily change
the tip of the branch back to the state before you ran them.
MERGE_HEAD
records the commit(s) which you are merging into your branch when you run gitmerge.
REBASE_HEAD
during a rebase, records the commit at which the operation is currently stopped, either because
of conflicts or an edit command in an interactive rebase.
REVERT_HEAD
records the commit which you are reverting when you run gitrevert.
CHERRY_PICK_HEAD
records the commit which you are cherry-picking when you run gitcherry-pick.
BISECT_HEAD
records the current commit to be tested when you run gitbisect--no-checkout.
AUTO_MERGE
records a tree object corresponding to the state the ort merge strategy wrote to the working tree
when a merge operation resulted in conflicts.
Note that any of the refs/* cases above may come either from the $GIT_DIR/refs directory or from the
$GIT_DIR/packed-refs file. While the ref name encoding is unspecified, UTF-8 is preferred as some
output processing may assume ref names in UTF-8.
@@ alone is a shortcut for HEAD.
[<refname>]@{<date>}, e.g. master@{yesterday}, HEAD@{5minutesago}
A ref followed by the suffix @ with a date specification enclosed in a brace pair (e.g. {yesterday},
{1month2weeks3days1hour1secondago} or {1979-02-2618:30:00}) specifies the value of the ref
at a prior point in time. This suffix may only be used immediately following a ref name and the ref
must have an existing log ($GIT_DIR/logs/<ref>). Note that this looks up the state of your local ref
at a given time; e.g., what was in your local master branch last week. If you want to look at commits
made during certain times, see --since and --until.
<refname>@{<n>}, e.g. master@{1}
A ref followed by the suffix @ with an ordinal specification enclosed in a brace pair (e.g. {1},
{15}) specifies the n-th prior value of that ref. For example master@{1} is the immediate prior value
of master while master@{5} is the 5th prior value of master. This suffix may only be used immediately
following a ref name and the ref must have an existing log ($GIT_DIR/logs/<refname>).
@{<n>}, e.g. @{1}
You can use the @ construct with an empty ref part to get at a reflog entry of the current branch.
For example, if you are on branch blabla then @{1} means the same as blabla@{1}.
@{-<n>}, e.g. @{-1}
The construct @{-<n>} means the <n>th branch/commit checked out before the current one.
[<branchname>]@{upstream}, e.g. master@{upstream}, @{u}
A branch B may be set up to build on top of a branch X (configured with branch.<name>.merge) at a
remote R (configured with the branch X taken from remote R, typically found at refs/remotes/R/X.
[<branchname>]@{push}, e.g. master@{push}, @{push}
The suffix @{push} reports the branch "where we would push to" if gitpush were run while branchname
was checked out (or the current HEAD if no branchname is specified). Like for @{upstream}, we report
the remote-tracking branch that corresponds to that branch at the remote.
Here’s an example to make it more clear:
$ git config push.default current
$ git config remote.pushdefault myfork
$ git switch -c mybranch origin/master
$ git rev-parse --symbolic-full-name @{upstream}
refs/remotes/origin/master
$ git rev-parse --symbolic-full-name @{push}
refs/remotes/myfork/mybranch
Note in the example that we set up a triangular workflow, where we pull from one location and push to
another. In a non-triangular workflow, @{push} is the same as @{upstream}, and there is no need for
it.
This suffix is also accepted when spelled in uppercase, and means the same thing no matter the case.
<rev>^[<n>], e.g. HEAD^,v1.5.1^0
A suffix ^ to a revision parameter means the first parent of that commit object. ^<n> means the
<n>th parent (i.e. <rev>^ is equivalent to <rev>^1). As a special rule, <rev>^0 means the commit
itself and is used when <rev> is the object name of a tag object that refers to a commit object.
<rev>~[<n>], e.g. HEAD~,master~3
A suffix ~ to a revision parameter means the first parent of that commit object. A suffix ~<n> to a
revision parameter means the commit object that is the <n>th generation ancestor of the named commit
object, following only the first parents. I.e. <rev>~3 is equivalent to <rev>^^^ which is equivalent
to <rev>^1^1^1. See below for an illustration of the usage of this form.
<rev>^{<type>}, e.g. v0.99.8^{commit}
A suffix ^ followed by an object type name enclosed in brace pair means dereference the object at
<rev> recursively until an object of type <type> is found or the object cannot be dereferenced
anymore (in which case, barf). For example, if <rev> is a commit-ish, <rev>^{commit} describes the
corresponding commit object. Similarly, if <rev> is a tree-ish, <rev>^{tree} describes the
corresponding tree object. <rev>^0 is a short-hand for <rev>^{commit}.
<rev>^{object} can be used to make sure <rev> names an object that exists, without requiring <rev> to
be a tag, and without dereferencing <rev>; because a tag is already an object, it does not have to be
dereferenced even once to get to an object.
<rev>^{tag} can be used to ensure that <rev> identifies an existing tag object.
<rev>^{}, e.g. v0.99.8^{}
A suffix ^ followed by an empty brace pair means the object could be a tag, and dereference the tag
recursively until a non-tag object is found.
<rev>^{/<text>}, e.g. HEAD^{/fixnastybug}
A suffix ^ to a revision parameter, followed by a brace pair that contains a text led by a slash, is
the same as the :/fixnastybug syntax below except that it returns the youngest matching commit
which is reachable from the <rev> before ^.
:/<text>, e.g. :/fixnastybug
A colon, followed by a slash, followed by a text, names a commit whose commit message matches the
specified regular expression. This name returns the youngest matching commit which is reachable from
any ref, including HEAD. The regular expression can match any part of the commit message. To match
messages starting with a string, one can use e.g. :/^foo. The special sequence :/! is reserved for
modifiers to what is matched. :/!-foo performs a negative match, while :/!!foo matches a literal !
character, followed by foo. Any other sequence beginning with :/! is reserved for now. Depending on
the given text, the shell’s word splitting rules might require additional quoting.
<rev>:<path>, e.g. HEAD:README, master:./README
A suffix : followed by a path names the blob or tree at the given path in the tree-ish object named
by the part before the colon. A path starting with ./ or ../ is relative to the current working
directory. The given path will be converted to be relative to the working tree’s root directory. This
is most useful to address a blob or tree from a commit or tree that has the same tree structure as
the working tree.
:[<n>:]<path>, e.g. :0:README, :README
A colon, optionally followed by a stage number (0 to 3) and a colon, followed by a path, names a blob
object in the index at the given path. A missing stage number (and the colon that follows it) names a
stage 0 entry. During a merge, stage 1 is the common ancestor, stage 2 is the target branch’s version
(typically the current branch), and stage 3 is the version from the branch which is being merged.
Here is an illustration, by Jon Loeliger. Both commit nodes B and C are parents of commit node A. Parent
commits are ordered left-to-right.
G H I J
\ / \ /
D E F
\ | / \
\ | / |
\|/ |
B C
\ /
\ /
A
A = = A^0
B = A^ = A^1 = A~1
C = = A^2
D = A^^ = A^1^1 = A~2
E = B^2 = A^^2
F = B^3 = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2 = B^^2 = A^^^2 = A~2^2
I = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2
Install Now
PNG Icons