| 1. | The Git User’s Manual |
NAME
gitglossary - A Git Glossary
SYNOPSIS
*
DESCRIPTION
alternate object database
bare repository
blob object
branch
cache
chain
changeset
checkout
cherry-picking
clean
commit
As a verb: The action of storing a new snapshot of the project’s 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.
commit graph concept, representations and usage
commit-graph file
commit object
commit-ish (also committish)
core Git
DAG
dangling object
dereference
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".
Referring to a commit object: the action of accessing the commit’s tree object. Commits cannot be dereferenced recursively.
Unless otherwise specified, "dereferencing" as it used in the context of Git commands or protocols is implicitly recursive.
detached HEAD
Note that commands that operate on the history of the current branch (e.g. git commit 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 about the current branch (e.g. git branch --set-upstream-to 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.
directory
dirty
evil merge
fast-forward
fetch
file system
Git archive
gitfile
grafts
Note that the grafts mechanism is outdated and can lead to problems transferring objects between repositories; see git-replace(1) for a more flexible and robust system to do the same thing.
hash
head
HEAD
head ref
hook
index
index entry
master
merge
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".
object
object database
object identifier (oid)
object name
object type
octopus
orphan
origin
overlay
pack
pack index
pathspec
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:
For example, Documentation/*.jpg will match all .jpg files in the Documentation subtree, including Documentation/chapter_1/figure_1.jpg.
A pathspec that begins with a colon : has special meaning. In the short form, the leading colon : is followed by zero or more "magic signature" letters (which optionally is terminated by another colon :), 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.
In the long form, the leading colon : 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.
A pathspec with only a colon means "there is no pathspec". This form should not be combined with other pathspec.
top
literal
icase
glob
Two consecutive asterisks ("**") in patterns matched against full pathname may have special meaning:
Glob magic is incompatible with literal magic.
attr
Each of the attribute requirements for the path takes one of these forms:
Note that when matching against a tree object, attributes are still obtained from working tree, not from the given tree object.
exclude
parent
peel
pickaxe
plumbing
porcelain
per-worktree ref
pseudoref
The following pseudorefs are known to Git:
pull
push
reachable
reachability bitmaps
rebase
ref
The ref namespace is hierarchical. Ref names must either start with refs/ or be located in the root of the hierarchy. For the latter, their name must follow these rules:
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:
Different subhierarchies are used for different purposes. For example, the refs/heads/ hierarchy is used to represent local branches whereas the refs/tags/ hierarchy is used to represent local tags..
reflog
refspec
remote repository
remote-tracking branch
repository
resolve
revision
rewind
SCM
SHA-1
shallow clone
shallow repository
stash entry
submodule
superproject
symref
tag
tag object
topic branch
tree
tree object
tree-ish (also treeish)
unborn
unmerged index
unreachable object
upstream branch
working tree
worktree
SEE ALSO
gittutorial(7), gittutorial-2(7), gitcvs-migration(7), giteveryday(7), The Git User’s Manual[1]
GIT
Part of the git(1) suite
NOTES
- 1.
The Git User’s Manual