Git glossary

This glossary introduces common Git terminology.


A branch is a parallel version of a repository. It is contained within the repository, but does not affect the primary or main branch allowing you to work freely without disrupting the "live" version. When you've made the changes you want to make, you can merge your branch back into the main branch to publish your changes.


You can use git checkout on the command line to create a new branch, change your current working branch to a different branch, or even to switch to a different version of a file from a different branch with git checkout [branchname] [path to file]. The "checkout" action updates all or part of the working tree with a tree object or blob from the object database, and updates the index and HEAD if the whole working tree is pointing to a new branch.

Checking out a branch updates the files in the working directory to match the version stored in that branch, and it tells Git to record all new commits on that branch. The git checkout command may occasionally be confused with git clone. The difference between the two commands is that clone works to fetch code from a remote repository, alternatively checkout works to switch between versions of code already on the local system.


To choose a subset of changes from 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 on another branch and to record it based on the tip of the current branch as a new commit. For more information, see git-cherry-pick in the Git documentation.


A working tree is clean if it corresponds to the revision referenced by the current HEAD. Also see "dirty".


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. When you make a clone, you can edit the files in your preferred editor and use Git to keep track of your changes without having to be online. The repository you cloned is still connected to the remote version so that you can push your local changes to the remote to keep them synced when you're online.


A commit, or "revision", is an individual change to a file (or set of files). When you make a commit to save your work, Git creates a unique ID (a.k.a. the "SHA" or "hash") that allows you to keep record of the specific changes committed along with who made them and when. Commits usually contain a commit message which is a brief description of what changes were made.

commit author

The user who makes the commit.

commit ID

Also known as SHA. A 40-character checksum hash that identifies the commit.

commit message

Short, descriptive text that accompanies a commit and communicates the change the commit is introducing.

default branch

The base branch for new pull requests and code commits in a repository. Each repository has at least one branch, which Git creates when you initialize the repository. The first branch is usually called main, and is often the default branch.

detached HEAD

Git will warn you if you're working on a detached HEAD, which means that Git is not pointing to a branch and that any commits you make will not appear in commit history. For example, when you check out an arbitrary commit that is not the latest commit of any particular branch, you're working on a "detached HEAD."


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.


A working tree is considered "dirty" if it contains modifications that have not been committed to the current branch.


A fast-forward is a special type of merge where you have a revision and you are "merging" another branch's 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 to this revision. This will happen frequently on a remote-tracking branch of a remote repository.

feature branch

A branch used to experiment with a new feature or fix an issue that is not in production. Also called a topic branch.

fenced code block

An indented block of code you can create with GitHub Flavored Markdown using triple backticks ``` before and after the code block. See this example.


When you use git fetch, you're adding changes from the remote repository to your local working branch without committing them. Unlike git pull, fetching allows you to review changes before committing them to your local branch.

If you see the branches in

branch -a
you have already fetched them.

You can verify this by giving the command

git show remotes/origin/some-branch:some-file

Or can do e.g.

diff remotes/origin/some-branch master

force push

A Git push that overwrites the remote repository with local changes without regard for conflicts.


A fork is a personal copy of another user's repository that lives on your account. Forks allow you to freely make changes to a project without affecting the original upstream repository. You can also open a pull request in the upstream repository and keep your fork synced with the latest changes since both repositories are still connected.


Git is an open source program for tracking changes in text files. It was written by the author of the Linux operating system, and is the core technology that GitHub, the social and user interface, is built on top of.


A plain .git file, which is always at the root of a working tree and points to the Git directory, which has the entire Git repository and its meta data. You can view this file for your repository on the command line with git rev-parse --git-dir. That is the real repository.

A defined commit of a branch, usually the most recent commit at the tip of the branch.

head branch

The branch whose changes are combined into the base branch when you merge a pull request. Also known as the "compare branch."


Human-readable nicknames that correspond to the address of a device connected to a network.

key fingerprint

A short sequence of bytes used to identify a longer public key.


A password management system in macOS.


Git Large File Storage. An open source Git extension for versioning large files.


The default development branch. Whenever you create a Git repository, a branch named main 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.


The default branch in many Git repositories. By default, when you create a new Git repository on the command line, a branch named master is created. Many tools now use an alternative name for the default branch. For example, when you create a new repository on GitHub, the default branch is named main.


Merging takes the changes from one branch (in the same repository or from a fork), and applies them into another. This often happens as a "pull request" (which can be thought of as a request to merge), or via the command line. A merge can be done through a pull request via the web interface if there are no conflicting changes, or can always be done via the command line.

merge conflict

A difference that occurs between merged branches. Merge conflicts happen when people make different changes to the same line of the same file, or when one person edits a file and another person deletes the same file. The merge conflict must be resolved before you can merge the branches.


A new copy of a repository.


When your local copy of a repository is out-of-sync with the upstream repository and you need to fetch the upstream changes before you push your local changes.

open source

Open source software is software that can be freely used, modified, and shared (in both modified and unmodified form) by anyone. Today the concept of "open source" is often extended beyond software, to represent a philosophy of collaboration in which working materials are made available online for anyone to fork, modify, discuss, and contribute to.


The default upstream repository. Most projects have at least one upstream project that they track. By default, origin is used for that purpose.


Pull refers to when you are fetching changes and merging them. For instance, if someone has edited the remote file you're both working on, you'll want to pull in those changes to your local copy so that it's up to date. See also fetch.


To push means to send your committed changes to a remote repository. For instance, if you change something locally, you can push those changes so that others may access them.

push a branch

When you successfully push a branch to a remote repository, you update the remote branch with changes from your local branch. When you "push a branch", Git will search for the branch's HEAD ref in the remote repository and verify that it is a direct ancestor to the branch's local HEAD ref. Once verified, Git pulls all objects (reachable from the local HEAD ref and missing from the remote repository) into the remote object database and then updates the remote HEAD ref. If the remote HEAD is not an ancestor to the local HEAD, the push fails.


To reapply a series of changes from a branch to a different base, and reset the HEAD of that branch to the result.


This is the version of a repository or branch that is hosted on a server. Remote versions can be connected to local clones so that changes can be synced.

remote repository

A repository that is used to track the same project but resides somewhere else.

remote URL

The place where your code is stored: a repository on GitHub, another user's fork, or even a different server.


A repository is the most basic element of GitHub. They're easiest to imagine as a project's folder. A repository contains all of the project files (including documentation), and stores each file's revision history. Repositories can have multiple collaborators and can be either public or private.


The action of fixing up manually what a failed automatic merge left behind.


A ref is an indirect way of referring to a commit. You can think of it as a user-friendly alias for a commit hash. This is Git’s internal mechanism of representing branches and tags. Refs are stored as normal text files in the .git/refs directory, where .git is usually named .git. The heads directory defines all of the local branches in your repository. Each filename matches the name of the corresponding branch, and inside the file you’ll find a commit hash. This commit hash is the location of the tip of the branch. Creating a new branch is simply a matter of writing a commit hash to a new file. The tags directory works the exact same way, but it contains tags instead of branches. The remotes directory lists all remote repositories that you created with git remote as separate subdirectories. Inside each one, you’ll find all the remote branches that have been fetched into your repository.


The reflog is Git’s safety net. It records almost every change you make in your repository, regardless of whether you committed a snapshot or not. You can think of it as a chronological history of everything you’ve done in your local repo. To view the reflog, run the git reflog command. it has a log of all commits made in the repo, as well as other actions, and we can use it to recover these lost commits. The HEAD{n} syntax lets you reference commits stored in the reflog. When we make changes to any branch, git stores those changes in the reflog. Even if we were to remove a whole bunch of work by resetting with the --hard flag, git still knows about the commits we had made and we can recover them. The key is that the commits still exist, there just aren’t any branches that currently point to them.

log --oneline

root directory

The first directory in a hierarchy.


To combine multiple commits into a single commit. Also a Git command.

topic branch

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. Can also be called a feature branch.

working area

The git working area contains the state of one branch at time. If you really want to have more than one branch checked out at a time you can clone your repo locally and checkout different branches into different work areas.


When talking about a branch or a fork, the primary branch on the original repository is often referred to as the "upstream", since that is the main place that other changes will come in from. The branch/fork you are working on is then called the "downstream". Also called origin.

upstream branch

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 A is origin/B sometimes we say "A is tracking origin/B".

Getting started