gitglossary.7 (32480B)
- '\" t
- .\" Title: gitglossary
- .\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
- .\" Generator: DocBook XSL Stylesheets v1.79.2 <http://docbook.sf.net/>
- .\" Date: 2025-03-14
- .\" Manual: Git Manual
- .\" Source: Git 2.49.0
- .\" Language: English
- .\"
- .TH "GITGLOSSARY" "7" "2025-03-14" "Git 2\&.49\&.0" "Git Manual"
- .\" -----------------------------------------------------------------
- .\" * Define some portability stuff
- .\" -----------------------------------------------------------------
- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- .\" http://bugs.debian.org/507673
- .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- .ie \n(.g .ds Aq \(aq
- .el .ds Aq '
- .\" -----------------------------------------------------------------
- .\" * set default formatting
- .\" -----------------------------------------------------------------
- .\" disable hyphenation
- .nh
- .\" disable justification (adjust text to left margin only)
- .ad l
- .\" -----------------------------------------------------------------
- .\" * MAIN CONTENT STARTS HERE *
- .\" -----------------------------------------------------------------
- .SH "NAME"
- gitglossary \- A Git Glossary
- .SH "SYNOPSIS"
- .sp
- *
- .SH "DESCRIPTION"
- .PP
- alternate object database
- .RS 4
- Via the alternates mechanism, a
- repository
- can inherit part of its
- object database
- from another object database, which is called an "alternate"\&.
- .RE
- .PP
- bare repository
- .RS 4
- A bare repository is normally an appropriately named
- directory
- with a \&.\fBgit\fR
- suffix that does not have a locally checked\-out copy of any of the files under revision control\&. That is, all of the Git administrative and control files that would normally be present in the hidden \&.\fBgit\fR
- sub\-directory are directly present in the
- \fBrepository\&.git\fR
- directory instead, and no other files are present and checked out\&. Usually publishers of public repositories make bare repositories available\&.
- .RE
- .PP
- blob object
- .RS 4
- Untyped
- object, e\&.g\&. the contents of a file\&.
- .RE
- .PP
- branch
- .RS 4
- A "branch" is a line of development\&. The most recent
- commit
- on a branch is referred to as the tip of that branch\&. The tip of the branch is
- referenced
- by a branch
- head, which moves forward as additional development is done on the branch\&. A single Git
- repository
- can track an arbitrary number of branches, but your
- working tree
- is associated with just one of them (the "current" or "checked out" branch), and
- HEAD
- points to that branch\&.
- .RE
- .PP
- cache
- .RS 4
- Obsolete for:
- index\&.
- .RE
- .PP
- chain
- .RS 4
- A list of objects, where each
- object
- in the list contains a reference to its successor (for example, the successor of a
- commit
- could be one of its
- parents)\&.
- .RE
- .PP
- changeset
- .RS 4
- BitKeeper/cvsps speak for "commit"\&. Since Git does not store changes, but states, it really does not make sense to use the term "changesets" with Git\&.
- .RE
- .PP
- checkout
- .RS 4
- The action of updating all or part of the
- working tree
- with a
- tree object
- or
- blob
- from the
- object database, and updating the
- index
- and
- HEAD
- if the whole working tree has been pointed at a new
- branch\&.
- .RE
- .PP
- cherry\-picking
- .RS 4
- In
- SCM
- jargon, "cherry pick" means to choose a subset of changes out of a series of changes (typically commits) and record them as a new series of changes on top of a different codebase\&. In Git, this is performed by the "git cherry\-pick" command to extract the change introduced by an existing
- commit
- and to record it based on the tip of the current
- branch
- as a new commit\&.
- .RE
- .PP
- clean
- .RS 4
- A
- working tree
- is clean, if it corresponds to the
- revision
- referenced by the current
- head\&. Also see "dirty"\&.
- .RE
- .PP
- commit
- .RS 4
- As a noun: A single point in the Git history; the entire history of a project is represented as a set of interrelated commits\&. The word "commit" is often used by Git in the same places other revision control systems use the words "revision" or "version"\&. Also used as a short hand for
- commit object\&.
- .sp
- As a verb: The action of storing a new snapshot of the project\(cqs state in the Git history, by creating a new commit representing the current state of the
- index
- and advancing
- HEAD
- to point at the new commit\&.
- .RE
- .PP
- commit graph concept, representations and usage
- .RS 4
- A synonym for the
- DAG
- structure formed by the commits in the object database,
- referenced
- by branch tips, using their
- chain
- of linked commits\&. This structure is the definitive commit graph\&. The graph can be represented in other ways, e\&.g\&. the
- "commit\-graph" file\&.
- .RE
- .PP
- commit\-graph file
- .RS 4
- The "commit\-graph" (normally hyphenated) file is a supplemental representation of the
- commit graph
- which accelerates commit graph walks\&. The "commit\-graph" file is stored either in the \&.git/objects/info directory or in the info directory of an alternate object database\&.
- .RE
- .PP
- commit object
- .RS 4
- An
- object
- which contains the information about a particular
- revision, such as
- parents, committer, author, date and the
- tree object
- which corresponds to the top
- directory
- of the stored revision\&.
- .RE
- .PP
- commit\-ish (also committish)
- .RS 4
- A
- commit object
- or an
- object
- that can be recursively
- dereferenced
- to a commit object\&. The following are all commit\-ishes: a commit object, a
- tag object
- that points to a commit object, a tag object that points to a tag object that points to a commit object, etc\&.
- .RE
- .PP
- core Git
- .RS 4
- Fundamental data structures and utilities of Git\&. Exposes only limited source code management tools\&.
- .RE
- .PP
- DAG
- .RS 4
- Directed acyclic graph\&. The
- commit objects
- form a directed acyclic graph, because they have parents (directed), and the graph of commit objects is acyclic (there is no
- chain
- which begins and ends with the same
- object)\&.
- .RE
- .PP
- dangling object
- .RS 4
- An
- unreachable object
- which is not
- reachable
- even from other unreachable objects; a dangling object has no references to it from any reference or
- object
- in the
- repository\&.
- .RE
- .PP
- dereference
- .RS 4
- Referring to a
- symbolic ref: the action of accessing the
- reference
- pointed at by a symbolic ref\&. Recursive dereferencing involves repeating the aforementioned process on the resulting ref until a non\-symbolic reference is found\&.
- .sp
- Referring to a
- tag object: the action of accessing the
- object
- a tag points at\&. Tags are recursively dereferenced by repeating the operation on the result object until the result has either a specified
- object type
- (where applicable) or any non\-"tag" object type\&. A synonym for "recursive dereference" in the context of tags is "peel"\&.
- .sp
- Referring to a
- commit object: the action of accessing the commit\(cqs tree object\&. Commits cannot be dereferenced recursively\&.
- .sp
- Unless otherwise specified, "dereferencing" as it used in the context of Git commands or protocols is implicitly recursive\&.
- .RE
- .PP
- detached HEAD
- .RS 4
- Normally the
- HEAD
- stores the name of a
- branch, and commands that operate on the history HEAD represents operate on the history leading to the tip of the branch the HEAD points at\&. However, Git also allows you to
- check out
- an arbitrary
- commit
- that isn\(cqt necessarily the tip of any particular branch\&. The HEAD in such a state is called "detached"\&.
- .sp
- Note that commands that operate on the history of the current branch (e\&.g\&.
- \fBgit\fR
- \fBcommit\fR
- to build a new history on top of it) still work while the HEAD is detached\&. They update the HEAD to point at the tip of the updated history without affecting any branch\&. Commands that update or inquire information
- \fIabout\fR
- the current branch (e\&.g\&.
- \fBgit\fR
- \fBbranch\fR
- \fB\-\-set\-upstream\-to\fR
- that sets what remote\-tracking branch the current branch integrates with) obviously do not work, as there is no (real) current branch to ask about in this state\&.
- .RE
- .PP
- directory
- .RS 4
- The list you get with "ls" :\-)
- .RE
- .PP
- dirty
- .RS 4
- A
- working tree
- is said to be "dirty" if it contains modifications which have not been
- committed
- to the current
- branch\&.
- .RE
- .PP
- evil merge
- .RS 4
- An evil merge is a
- merge
- that introduces changes that do not appear in any
- parent\&.
- .RE
- .PP
- fast\-forward
- .RS 4
- A fast\-forward is a special type of
- merge
- where you have a
- revision
- and you are "merging" another
- branch\*(Aqs changes that happen to be a descendant of what you have\&. In such a case, you do not make a new
- merge
- commit
- but instead just update your branch to point at the same revision as the branch you are merging\&. This will happen frequently on a
- remote\-tracking branch
- of a remote
- repository\&.
- .RE
- .PP
- fetch
- .RS 4
- Fetching a
- branch
- means to get the branch\(cqs
- head ref
- from a remote
- repository, to find out which objects are missing from the local
- object database, and to get them, too\&. See also
- \fBgit-fetch\fR(1)\&.
- .RE
- .PP
- file system
- .RS 4
- Linus Torvalds originally designed Git to be a user space file system, i\&.e\&. the infrastructure to hold files and directories\&. That ensured the efficiency and speed of Git\&.
- .RE
- .PP
- Git archive
- .RS 4
- Synonym for
- repository
- (for arch people)\&.
- .RE
- .PP
- gitfile
- .RS 4
- A plain file \&.\fBgit\fR
- at the root of a working tree that points at the directory that is the real repository\&. For proper use see
- \fBgit-worktree\fR(1)
- or
- \fBgit-submodule\fR(1)\&. For syntax see
- \fBgitrepository-layout\fR(5)\&.
- .RE
- .PP
- grafts
- .RS 4
- Grafts enable two otherwise different lines of development to be joined together by recording fake ancestry information for commits\&. This way you can make Git pretend the set of
- parents
- a
- commit
- has is different from what was recorded when the commit was created\&. Configured via the \&.\fBgit/info/grafts\fR
- file\&.
- .sp
- Note that the grafts mechanism is outdated and can lead to problems transferring objects between repositories; see
- \fBgit-replace\fR(1)
- for a more flexible and robust system to do the same thing\&.
- .RE
- .PP
- hash
- .RS 4
- In Git\(cqs context, synonym for
- object name\&.
- .RE
- .PP
- head
- .RS 4
- A
- named reference
- to the
- commit
- at the tip of a
- branch\&. Heads are stored in a file in
- \fB$GIT_DIR/refs/heads/\fR
- directory, except when using packed refs\&. (See
- \fBgit-pack-refs\fR(1)\&.)
- .RE
- .PP
- HEAD
- .RS 4
- The current
- branch\&. In more detail: Your
- working tree
- is normally derived from the state of the tree referred to by HEAD\&. HEAD is a reference to one of the
- heads
- in your repository, except when using a
- detached HEAD, in which case it directly references an arbitrary commit\&.
- .RE
- .PP
- head ref
- .RS 4
- A synonym for
- head\&.
- .RE
- .PP
- hook
- .RS 4
- During the normal execution of several Git commands, call\-outs are made to optional scripts that allow a developer to add functionality or checking\&. Typically, the hooks allow for a command to be pre\-verified and potentially aborted, and allow for a post\-notification after the operation is done\&. The hook scripts are found in the
- \fB$GIT_DIR/hooks/\fR
- directory, and are enabled by simply removing the \&.\fBsample\fR
- suffix from the filename\&. In earlier versions of Git you had to make them executable\&.
- .RE
- .PP
- index
- .RS 4
- A collection of files with stat information, whose contents are stored as objects\&. The index is a stored version of your
- working tree\&. Truth be told, it can also contain a second, and even a third version of a working tree, which are used when
- merging\&.
- .RE
- .PP
- index entry
- .RS 4
- The information regarding a particular file, stored in the
- index\&. An index entry can be unmerged, if a
- merge
- was started, but not yet finished (i\&.e\&. if the index contains multiple versions of that file)\&.
- .RE
- .PP
- master
- .RS 4
- The default development
- branch\&. Whenever you create a Git
- repository, a branch named "master" is created, and becomes the active branch\&. In most cases, this contains the local development, though that is purely by convention and is not required\&.
- .RE
- .PP
- merge
- .RS 4
- As a verb: To bring the contents of another
- branch
- (possibly from an external
- repository) into the current branch\&. In the case where the merged\-in branch is from a different repository, this is done by first
- fetching
- the remote branch and then merging the result into the current branch\&. This combination of fetch and merge operations is called a
- pull\&. Merging is performed by an automatic process that identifies changes made since the branches diverged, and then applies all those changes together\&. In cases where changes conflict, manual intervention may be required to complete the merge\&.
- .sp
- As a noun: unless it is a
- fast\-forward, a successful merge results in the creation of a new
- commit
- representing the result of the merge, and having as
- parents
- the tips of the merged
- branches\&. This commit is referred to as a "merge commit", or sometimes just a "merge"\&.
- .RE
- .PP
- object
- .RS 4
- The unit of storage in Git\&. It is uniquely identified by the
- SHA\-1
- of its contents\&. Consequently, an object cannot be changed\&.
- .RE
- .PP
- object database
- .RS 4
- Stores a set of "objects", and an individual
- object
- is identified by its
- object name\&. The objects usually live in
- \fB$GIT_DIR/objects/\fR\&.
- .RE
- .PP
- object identifier (oid)
- .RS 4
- Synonym for
- object name\&.
- .RE
- .PP
- object name
- .RS 4
- The unique identifier of an
- object\&. The object name is usually represented by a 40 character hexadecimal string\&. Also colloquially called
- SHA\-1\&.
- .RE
- .PP
- object type
- .RS 4
- One of the identifiers "commit", "tree", "tag" or "blob" describing the type of an
- object\&.
- .RE
- .PP
- octopus
- .RS 4
- To
- merge
- more than two
- branches\&.
- .RE
- .PP
- orphan
- .RS 4
- The act of getting on a
- branch
- that does not exist yet (i\&.e\&., an
- unborn
- branch)\&. After such an operation, the commit first created becomes a commit without a parent, starting a new history\&.
- .RE
- .PP
- origin
- .RS 4
- The default upstream
- repository\&. Most projects have at least one upstream project which they track\&. By default
- \fIorigin\fR
- is used for that purpose\&. New upstream updates will be fetched into
- remote\-tracking branches
- named origin/name\-of\-upstream\-branch, which you can see using
- \fBgit\fR
- \fBbranch\fR
- \fB\-r\fR\&.
- .RE
- .PP
- overlay
- .RS 4
- Only update and add files to the working directory, but don\(cqt delete them, similar to how
- \fIcp \-R\fR
- would update the contents in the destination directory\&. This is the default mode in a
- checkout
- when checking out files from the
- index
- or a
- tree\-ish\&. In contrast, no\-overlay mode also deletes tracked files not present in the source, similar to
- \fIrsync \-\-delete\fR\&.
- .RE
- .PP
- pack
- .RS 4
- A set of objects which have been compressed into one file (to save space or to transmit them efficiently)\&.
- .RE
- .PP
- pack index
- .RS 4
- The list of identifiers, and other information, of the objects in a
- pack, to assist in efficiently accessing the contents of a pack\&.
- .RE
- .PP
- pathspec
- .RS 4
- Pattern used to limit paths in Git commands\&.
- .sp
- Pathspecs are used on the command line of "git ls\-files", "git ls\-tree", "git add", "git grep", "git diff", "git checkout", and many other commands to limit the scope of operations to some subset of the tree or working tree\&. See the documentation of each command for whether paths are relative to the current directory or toplevel\&. The pathspec syntax is as follows:
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- any path matches itself
- .RE
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- the pathspec up to the last slash represents a directory prefix\&. The scope of that pathspec is limited to that subtree\&.
- .RE
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- the rest of the pathspec is a pattern for the remainder of the pathname\&. Paths relative to the directory prefix will be matched against that pattern using fnmatch(3); in particular,
- \fI*\fR
- and
- \fI?\fR
- \fIcan\fR
- match directory separators\&.
- .RE
- .sp
- For example, Documentation/*\&.jpg will match all \&.jpg files in the Documentation subtree, including Documentation/chapter_1/figure_1\&.jpg\&.
- .sp
- A pathspec that begins with a colon
- \fB:\fR
- has special meaning\&. In the short form, the leading colon
- \fB:\fR
- is followed by zero or more "magic signature" letters (which optionally is terminated by another colon
- \fB:\fR), and the remainder is the pattern to match against the path\&. The "magic signature" consists of ASCII symbols that are neither alphanumeric, glob, regex special characters nor colon\&. The optional colon that terminates the "magic signature" can be omitted if the pattern begins with a character that does not belong to "magic signature" symbol set and is not a colon\&.
- .sp
- In the long form, the leading colon
- \fB:\fR
- is followed by an open parenthesis (, a comma\-separated list of zero or more "magic words", and a close parentheses ), and the remainder is the pattern to match against the path\&.
- .sp
- A pathspec with only a colon means "there is no pathspec"\&. This form should not be combined with other pathspec\&.
- .PP
- top
- .RS 4
- The magic word
- \fBtop\fR
- (magic signature:
- \fB/\fR) makes the pattern match from the root of the working tree, even when you are running the command from inside a subdirectory\&.
- .RE
- .PP
- literal
- .RS 4
- Wildcards in the pattern such as * or ? are treated as literal characters\&.
- .RE
- .PP
- icase
- .RS 4
- Case insensitive match\&.
- .RE
- .PP
- glob
- .RS 4
- Git treats the pattern as a shell glob suitable for consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in the pattern will not match a / in the pathname\&. For example, "Documentation/*\&.html" matches "Documentation/git\&.html" but not "Documentation/ppc/ppc\&.html" or "tools/perf/Documentation/perf\&.html"\&.
- .sp
- Two consecutive asterisks ("**") in patterns matched against full pathname may have special meaning:
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- A leading "**" followed by a slash means match in all directories\&. For example, "**/foo" matches file or directory "\fBfoo\fR" anywhere, the same as pattern "\fBfoo\fR"\&. "**/foo/bar" matches file or directory "\fBbar\fR" anywhere that is directly under directory "\fBfoo\fR"\&.
- .RE
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- A trailing "\fB/\fR**" matches everything inside\&. For example, "\fBabc/\fR**" matches all files inside directory "abc", relative to the location of the \&.\fBgitignore\fR
- file, with infinite depth\&.
- .RE
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- A slash followed by two consecutive asterisks then a slash matches zero or more directories\&. For example, "\fBa/\fR**/b" matches "\fBa/b\fR", "\fBa/x/b\fR", "\fBa/x/y/b\fR" and so on\&.
- .RE
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- Other consecutive asterisks are considered invalid\&.
- .sp
- Glob magic is incompatible with literal magic\&.
- .RE
- .RE
- .PP
- attr
- .RS 4
- After
- \fBattr:\fR
- comes a space separated list of "attribute requirements", all of which must be met in order for the path to be considered a match; this is in addition to the usual non\-magic pathspec pattern matching\&. See
- \fBgitattributes\fR(5)\&.
- .sp
- Each of the attribute requirements for the path takes one of these forms:
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- "\fBATTR\fR" requires that the attribute
- \fBATTR\fR
- be set\&.
- .RE
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- "\fB\-ATTR\fR" requires that the attribute
- \fBATTR\fR
- be unset\&.
- .RE
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- "\fBATTR=VALUE\fR" requires that the attribute
- \fBATTR\fR
- be set to the string
- \fBVALUE\fR\&.
- .RE
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- "!ATTR" requires that the attribute
- \fBATTR\fR
- be unspecified\&.
- .sp
- Note that when matching against a tree object, attributes are still obtained from working tree, not from the given tree object\&.
- .RE
- .RE
- .PP
- exclude
- .RS 4
- After a path matches any non\-exclude pathspec, it will be run through all exclude pathspecs (magic signature: ! or its synonym
- \fB^\fR)\&. If it matches, the path is ignored\&. When there is no non\-exclude pathspec, the exclusion is applied to the result set as if invoked without any pathspec\&.
- .RE
- .RE
- .PP
- parent
- .RS 4
- A
- commit object
- contains a (possibly empty) list of the logical predecessor(s) in the line of development, i\&.e\&. its parents\&.
- .RE
- .PP
- peel
- .RS 4
- The action of recursively
- dereferencing
- a
- tag object\&.
- .RE
- .PP
- pickaxe
- .RS 4
- The term
- pickaxe
- refers to an option to the diffcore routines that help select changes that add or delete a given text string\&. With the
- \fB\-\-pickaxe\-all\fR
- option, it can be used to view the full
- changeset
- that introduced or removed, say, a particular line of text\&. See
- \fBgit-diff\fR(1)\&.
- .RE
- .PP
- plumbing
- .RS 4
- Cute name for
- core Git\&.
- .RE
- .PP
- porcelain
- .RS 4
- Cute name for programs and program suites depending on
- core Git, presenting a high level access to core Git\&. Porcelains expose more of a
- SCM
- interface than the
- plumbing\&.
- .RE
- .PP
- per\-worktree ref
- .RS 4
- Refs that are per\-worktree, rather than global\&. This is presently only
- HEAD
- and any refs that start with
- \fBrefs/bisect/\fR, but might later include other unusual refs\&.
- .RE
- .PP
- pseudoref
- .RS 4
- A ref that has different semantics than normal refs\&. These refs can be read via normal Git commands, but cannot be written to by commands like
- \fBgit-update-ref\fR(1)\&.
- .sp
- The following pseudorefs are known to Git:
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- \fBFETCH_HEAD\fR
- is written by
- \fBgit-fetch\fR(1)
- or
- \fBgit-pull\fR(1)\&. It may refer to multiple object IDs\&. Each object ID is annotated with metadata indicating where it was fetched from and its fetch status\&.
- .RE
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- \fBMERGE_HEAD\fR
- is written by
- \fBgit-merge\fR(1)
- when resolving merge conflicts\&. It contains all commit IDs which are being merged\&.
- .RE
- .RE
- .PP
- pull
- .RS 4
- Pulling a
- branch
- means to
- fetch
- it and
- merge
- it\&. See also
- \fBgit-pull\fR(1)\&.
- .RE
- .PP
- push
- .RS 4
- Pushing a
- branch
- means to get the branch\(cqs
- head ref
- from a remote
- repository, find out if it is an ancestor to the branch\(cqs local head ref, and in that case, putting all objects, which are
- reachable
- from the local head ref, and which are missing from the remote repository, into the remote
- object database, and updating the remote head ref\&. If the remote
- head
- is not an ancestor to the local head, the push fails\&.
- .RE
- .PP
- reachable
- .RS 4
- All of the ancestors of a given
- commit
- are said to be "reachable" from that commit\&. More generally, one
- object
- is reachable from another if we can reach the one from the other by a
- chain
- that follows
- tags
- to whatever they tag,
- commits
- to their parents or trees, and
- trees
- to the trees or
- blobs
- that they contain\&.
- .RE
- .PP
- reachability bitmaps
- .RS 4
- Reachability bitmaps store information about the
- reachability
- of a selected set of commits in a packfile, or a multi\-pack index (MIDX), to speed up object search\&. The bitmaps are stored in a "\&.bitmap" file\&. A repository may have at most one bitmap file in use\&. The bitmap file may belong to either one pack, or the repository\(cqs multi\-pack index (if it exists)\&.
- .RE
- .PP
- rebase
- .RS 4
- To reapply a series of changes from a
- branch
- to a different base, and reset the
- head
- of that branch to the result\&.
- .RE
- .PP
- ref
- .RS 4
- A name that points to an
- object name
- or another ref (the latter is called a
- symbolic ref)\&. For convenience, a ref can sometimes be abbreviated when used as an argument to a Git command; see
- \fBgitrevisions\fR(7)
- for details\&. Refs are stored in the
- repository\&.
- .sp
- The ref namespace is hierarchical\&. Ref names must either start with
- \fBrefs/\fR
- or be located in the root of the hierarchy\&. For the latter, their name must follow these rules:
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- The name consists of only upper\-case characters or underscores\&.
- .RE
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- The name ends with "\fB_HEAD\fR" or is equal to "\fBHEAD\fR"\&.
- .sp
- There are some irregular refs in the root of the hierarchy that do not match these rules\&. The following list is exhaustive and shall not be extended in the future:
- .RE
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- \fBAUTO_MERGE\fR
- .RE
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- \fBBISECT_EXPECTED_REV\fR
- .RE
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- \fBNOTES_MERGE_PARTIAL\fR
- .RE
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- \fBNOTES_MERGE_REF\fR
- .RE
- .sp
- .RS 4
- .ie n \{\
- \h'-04'\(bu\h'+03'\c
- .\}
- .el \{\
- .sp -1
- .IP \(bu 2.3
- .\}
- \fBMERGE_AUTOSTASH\fR
- .sp
- Different subhierarchies are used for different purposes\&. For example, the
- \fBrefs/heads/\fR
- hierarchy is used to represent local branches whereas the
- \fBrefs/tags/\fR
- hierarchy is used to represent local tags\&.\&.
- .RE
- .RE
- .PP
- reflog
- .RS 4
- A reflog shows the local "history" of a ref\&. In other words, it can tell you what the 3rd last revision in
- \fIthis\fR
- repository was, and what was the current state in
- \fIthis\fR
- repository, yesterday 9:14pm\&. See
- \fBgit-reflog\fR(1)
- for details\&.
- .RE
- .PP
- refspec
- .RS 4
- A "refspec" is used by
- fetch
- and
- push
- to describe the mapping between remote
- ref
- and local ref\&. See
- \fBgit-fetch\fR(1)
- or
- \fBgit-push\fR(1)
- for details\&.
- .RE
- .PP
- remote repository
- .RS 4
- A
- repository
- which is used to track the same project but resides somewhere else\&. To communicate with remotes, see
- fetch
- or
- push\&.
- .RE
- .PP
- remote\-tracking branch
- .RS 4
- A
- ref
- that is used to follow changes from another
- repository\&. It typically looks like
- \fIrefs/remotes/foo/bar\fR
- (indicating that it tracks a branch named
- \fIbar\fR
- in a remote named
- \fIfoo\fR), and matches the right\-hand\-side of a configured fetch
- refspec\&. A remote\-tracking branch should not contain direct modifications or have local commits made to it\&.
- .RE
- .PP
- repository
- .RS 4
- A collection of
- refs
- together with an
- object database
- containing all objects which are
- reachable
- from the refs, possibly accompanied by meta data from one or more
- porcelains\&. A repository can share an object database with other repositories via
- alternates mechanism\&.
- .RE
- .PP
- resolve
- .RS 4
- The action of fixing up manually what a failed automatic
- merge
- left behind\&.
- .RE
- .PP
- revision
- .RS 4
- Synonym for
- commit
- (the noun)\&.
- .RE
- .PP
- rewind
- .RS 4
- To throw away part of the development, i\&.e\&. to assign the
- head
- to an earlier
- revision\&.
- .RE
- .PP
- SCM
- .RS 4
- Source code management (tool)\&.
- .RE
- .PP
- SHA\-1
- .RS 4
- "Secure Hash Algorithm 1"; a cryptographic hash function\&. In the context of Git used as a synonym for
- object name\&.
- .RE
- .PP
- shallow clone
- .RS 4
- Mostly a synonym to
- shallow repository
- but the phrase makes it more explicit that it was created by running
- \fBgit\fR
- \fBclone\fR
- \fB\-\-depth=\&.\&.\fR\&. command\&.
- .RE
- .PP
- shallow repository
- .RS 4
- A shallow
- repository
- has an incomplete history some of whose
- commits
- have
- parents
- cauterized away (in other words, Git is told to pretend that these commits do not have the parents, even though they are recorded in the
- commit object)\&. This is sometimes useful when you are interested only in the recent history of a project even though the real history recorded in the upstream is much larger\&. A shallow repository is created by giving the
- \fB\-\-depth\fR
- option to
- \fBgit-clone\fR(1), and its history can be later deepened with
- \fBgit-fetch\fR(1)\&.
- .RE
- .PP
- stash entry
- .RS 4
- An
- object
- used to temporarily store the contents of a
- dirty
- working directory and the index for future reuse\&.
- .RE
- .PP
- submodule
- .RS 4
- A
- repository
- that holds the history of a separate project inside another repository (the latter of which is called
- superproject)\&.
- .RE
- .PP
- superproject
- .RS 4
- A
- repository
- that references repositories of other projects in its working tree as
- submodules\&. The superproject knows about the names of (but does not hold copies of) commit objects of the contained submodules\&.
- .RE
- .PP
- symref
- .RS 4
- Symbolic reference: instead of containing the
- SHA\-1
- id itself, it is of the format
- \fIref: refs/some/thing\fR
- and when referenced, it recursively
- dereferences
- to this reference\&.
- \fIHEAD\fR
- is a prime example of a symref\&. Symbolic references are manipulated with the
- \fBgit-symbolic-ref\fR(1)
- command\&.
- .RE
- .PP
- tag
- .RS 4
- A
- ref
- under
- \fBrefs/tags/\fR
- namespace that points to an object of an arbitrary type (typically a tag points to either a
- tag
- or a
- commit object)\&. In contrast to a
- head, a tag is not updated by the
- \fBcommit\fR
- command\&. A Git tag has nothing to do with a Lisp tag (which would be called an
- object type
- in Git\(cqs context)\&. A tag is most typically used to mark a particular point in the commit ancestry
- chain\&.
- .RE
- .PP
- tag object
- .RS 4
- An
- object
- containing a
- ref
- pointing to another object, which can contain a message just like a
- commit object\&. It can also contain a (PGP) signature, in which case it is called a "signed tag object"\&.
- .RE
- .PP
- topic branch
- .RS 4
- A regular Git
- branch
- that is used by a developer to identify a conceptual line of development\&. Since branches are very easy and inexpensive, it is often desirable to have several small branches that each contain very well defined concepts or small incremental yet related changes\&.
- .RE
- .PP
- trailer
- .RS 4
- Key\-value metadata\&. Trailers are optionally found at the end of a commit message\&. Might be called "footers" or "tags" in other communities\&. See
- \fBgit-interpret-trailers\fR(1)\&.
- .RE
- .PP
- tree
- .RS 4
- Either a
- working tree, or a
- tree object
- together with the dependent
- blob
- and tree objects (i\&.e\&. a stored representation of a working tree)\&.
- .RE
- .PP
- tree object
- .RS 4
- An
- object
- containing a list of file names and modes along with refs to the associated blob and/or tree objects\&. A
- tree
- is equivalent to a
- directory\&.
- .RE
- .PP
- tree\-ish (also treeish)
- .RS 4
- A
- tree object
- or an
- object
- that can be recursively
- dereferenced
- to a tree object\&. Dereferencing a
- commit object
- yields the tree object corresponding to the
- revision\*(Aqs top
- directory\&. The following are all tree\-ishes: a
- commit\-ish, a tree object, a
- tag object
- that points to a tree object, a tag object that points to a tag object that points to a tree object, etc\&.
- .RE
- .PP
- unborn
- .RS 4
- The
- HEAD
- can point at a
- branch
- that does not yet exist and that does not have any commit on it yet, and such a branch is called an unborn branch\&. The most typical way users encounter an unborn branch is by creating a repository anew without cloning from elsewhere\&. The HEAD would point at the
- \fImain\fR
- (or
- \fImaster\fR, depending on your configuration) branch that is yet to be born\&. Also some operations can get you on an unborn branch with their
- orphan
- option\&.
- .RE
- .PP
- unmerged index
- .RS 4
- An
- index
- which contains unmerged
- index entries\&.
- .RE
- .PP
- unreachable object
- .RS 4
- An
- object
- which is not
- reachable
- from a
- branch,
- tag, or any other reference\&.
- .RE
- .PP
- upstream branch
- .RS 4
- The default
- branch
- that is merged into the branch in question (or the branch in question is rebased onto)\&. It is configured via branch\&.<name>\&.remote and branch\&.<name>\&.merge\&. If the upstream branch of
- \fIA\fR
- is
- \fIorigin/B\fR
- sometimes we say "\fIA\fR
- is tracking
- \fIorigin/B\fR"\&.
- .RE
- .PP
- working tree
- .RS 4
- The tree of actual checked out files\&. The working tree normally contains the contents of the
- HEAD
- commit\(cqs tree, plus any local changes that you have made but not yet committed\&.
- .RE
- .PP
- worktree
- .RS 4
- A repository can have zero (i\&.e\&. bare repository) or one or more worktrees attached to it\&. One "worktree" consists of a "working tree" and repository metadata, most of which are shared among other worktrees of a single repository, and some of which are maintained separately per worktree (e\&.g\&. the index, HEAD and pseudorefs like MERGE_HEAD, per\-worktree refs and per\-worktree configuration file)\&.
- .RE
- .SH "SEE ALSO"
- .sp
- \fBgittutorial\fR(7), \fBgittutorial-2\fR(7), \fBgitcvs-migration\fR(7), \fBgiteveryday\fR(7), \m[blue]\fBThe Git User\(cqs Manual\fR\m[]\&\s-2\u[1]\d\s+2
- .SH "GIT"
- .sp
- Part of the \fBgit\fR(1) suite
- .SH "NOTES"
- .IP " 1." 4
- The Git User\(cqs Manual
- .RS 4
- \%git-htmldocs/user-manual.html
- .RE