Git glossary (short version)

Introduction

On git-scm.com a complete Git glossary is provided. We quote this website but list only the meaning of the most important terms. Visit git-scm.com/docs/gitglossary to get the full list. Some more or solely GitHub related descriptions are taken from help.github.com/articles/github-glossary.

A good overview of the Git Client-Host communication commands is given by Oliver Steele in this image:

and for a general Git workflow in this image:

Glossary

• bare repository

  A bare repository is normally an appropriately named directory with a .git 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 .git sub-directory are directly present in the repository.git directory instead, and no other files are present and checked out. Usually publishers of public repositories make bare repositories available.

• branch

  A "branch" is an active 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.

• checkout

  The action of updating all or part of the working tree ... from the object database, and updating the index and HEAD if the whole working tree has been pointed at a new branch.

• clean

  A working tree is clean, if it corresponds to the commit referenced by the current head. ...

• clone

  A clone is a copy of a repository that lives on your computer instead of on a website's server somewhere, or the act of making that copy. With your clone you can edit the files in your preferred editor and use Git to keep track of your changes without having to be online. It is, however, connected to the remote version so that changes can be synced between the two. You can push your local changes to the remote to keep them synced when you're online.

• collaborator

  A collaborator is a person with read and write access to a repository who has been invited to contribute by the repository owner.

• commit

  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". ...

  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.

• contributor

  A contributor is someone who has contributed to a project by having a pull request merged but does not have collaborator access.

• detached HEAD

  Normally the HEAD stores the name of a branch, and commands that 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’t necessarily the tip of any particular branch. The HEAD in such a state is called "detached".

  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.

• diff

  A diff is the difference in changes between two commits, or saved changes. The diff will visually describe what was added or removed from a file since its last commit.

• dirty

  A working tree is said to be "dirty" if it contains modifications which have not been committed to the current branch.

• fetch

  Fetching a branch means to get the branch’s head from a remote repository, to find out which objects are missing from the local object database, and to get them, too. See also git-fetch[1].

• fork

  A fork is a personal copy of another (N.B.: GitHub) user's repository that lives on your (N.B.: GitHub) account. Forks allow you to freely make changes to a project without affecting the original. Forks remain attached to the original, allowing you to submit a pull request to the original's author to update with your changes. You can also keep your fork up to date by pulling in updates from the original.

• Git

  Git is an open source program for tracking changes in text files, and is the core technology that GitHub, the social and user interface, is built on top of.

• head

  A named reference to the commit at the tip of a branch. Heads are stored in a file in $GIT_DIR/refs/heads/ directory ... .

• HEAD

  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.

• index

  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.

• issue

  Issues are suggested improvements, tasks or questions related to the repository. Issues can be created by anyone (for public repositories), and are moderated by repository collaborators. Each issue contains its own discussion forum, can be labelled and assigned to a (N.B.: GitHub) user.

• master

  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.

• merge

  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.

  As a noun: ... 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

  The unit of storage in Git. It is uniquely identified by the SHA-1 of its contents. Consequently, an object can not be changed.

• origin

  The default upstream repository. Most projects have at least one upstream project which they track. By default origin 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 git branch -r.

• parent

  A commit object contains a (possibly empty) list of the logical predecessor(s) in the line of development, i.e. its parents.

• pull

  Pulling a branch means to fetch it and merge it. See also git-pull[1].

• pull request

  Pull requests are proposed changes to a repository submitted by a (N.B.: GitHub) user and accepted or rejected by a repository's collaborators. Like issues, pull requests each have their own discussion forum. For more information, see "About pull requests."

• push

  Pushing a branch means to get the branch’s head ref from a remote repository, find out if it is an ancestor to the branch’s 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.

• remote repository

  A repository which is used to track the same project but resides somewhere else. To communicate with remotes, see fetch or push.

• remote-tracking branch

  A ref that is used to follow changes from another repository. It typically looks like refs/remotes/foo/bar (indicating that it tracks a branch named bar in a remote named foo) ... . A remote-tracking branch should not contain direct modifications or have local commits made to it.

• repository

  A collection of refs together with an object database ... .

• SCM

  Source code management (tool).

• SHA-1

  "Secure Hash Algorithm 1"; a cryptographic hash function. In the context of Git used as a synonym for object name.

• stash entry

  An object used to temporarily store the contents of a dirty working directory and the index for future reuse.

• submodule

  A repository that holds the history of a separate project inside another repository (the latter of which is called superproject).

• superproject

  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.

• working tree

  The tree of actual checked out files. The working tree normally contains the contents of the HEAD commit’s tree, plus any local changes that you have made but not yet committed.