Git Glossary
Over 60 Git terms defined clearly, with examples. Use this as a reference when documentation or a colleague uses terminology you are not familiar with.
Core Objects and Storage
Term | Definition | Example |
|---|---|---|
Repository (repo) | A directory that Git manages. Contains all versions of all files, the full commit history, branches, and tags. Stored in the hidden |
|
Commit | A snapshot of the entire repository at a specific point in time. Identified by a unique SHA-1 hash. Contains the author, date, message, and a pointer to the root tree object. |
|
Tree object | An internal Git object representing a directory. Contains pointers to blob objects (files) and other tree objects (subdirectories). | The root tree of a commit represents the top-level directory. |
Blob object | An internal Git object storing the raw content of a file — with no filename. The filename is stored in the tree that points to the blob. |
|
Tag object | An annotated tag is a full Git object with tagger name, date, and message. A lightweight tag is just a named pointer to a commit. |
|
Ref | A human-readable name (pointer) to a commit SHA. All branches and tags are refs. |
|
Refspec | A pattern that maps remote refs to local refs. Used by fetch/push to know which refs to transfer. |
|
Packfile | A compressed file storing many Git objects efficiently using delta compression. Reduces repository size dramatically compared to storing loose objects. | Visible in |
Object database | The content-addressable store in | Every object is stored at a path derived from its SHA-1 hash. |
Working Areas
Term | Definition | Example |
|---|---|---|
Working tree | The directory you see and edit files in — the current checkout of a specific version of the project. | When you edit |
Index | Another name for the staging area. A binary file |
|
Staging area | The intermediate area between the working tree and the repository. Files added with |
|
Stash | A stack of saved dirty working tree states. Lets you set aside uncommitted changes temporarily without committing them. |
|
Worktree | A linked working directory that shares the same |
|
Branches and Refs
Term | Definition | Example |
|---|---|---|
Branch | A lightweight, movable pointer to a commit. When you commit on a branch, the pointer automatically advances to the new commit. |
|
HEAD | A special ref pointing to the current commit (what is checked out). Usually points to a branch; when it points directly to a commit, you are in detached HEAD state. |
|
Detached HEAD | State where HEAD points directly to a commit SHA rather than to a branch name. Commits made here are not on any named branch and may be garbage-collected. |
|
upstream (branch) | The remote-tracking branch that a local branch is configured to track. |
|
Remote | A named reference to another Git repository. The most common remote is |
|
origin | The conventional name for the remote you cloned from. Just a convention — the name can be anything. |
|
upstream (remote) | In open-source fork workflows, the conventional name for the original repository you forked from (as opposed to |
|
Remote-tracking branch | A read-only local reference to the state of a branch on a remote. Updated by |
|
Tracking branch | A local branch with an upstream configured. |
|
ORIG_HEAD | A ref created automatically before operations that change HEAD dramatically (merge, rebase, reset). Allows undo. |
|
FETCH_HEAD | Records the branch/commit fetched in the most recent |
|
MERGE_HEAD | Points to the commit being merged during an in-progress merge. | Exists only while a merge is paused for conflict resolution. |
Mainline | The primary integration branch of a project — usually | All feature branches merge back to the mainline. |
History and Rewriting
Term | Definition | Example |
|---|---|---|
Merge | The act of integrating changes from one branch into another. Creates a merge commit (in a no-fast-forward merge) that has two parents. |
|
Fast-forward merge | A merge where the target branch has not diverged — Git simply advances the branch pointer to the source commit. No merge commit is created. |
|
Three-way merge | The standard merge algorithm. Finds the common ancestor of both branches and compares both sides' changes relative to it. Required when both branches have new commits. | Happens automatically when both branches have diverged. |
Merge commit | A commit with two parent commits, created by a non-fast-forward merge. Marks where two branches were joined. | Has a message like "Merge branch 'feature' into main" |
Rebase | Moves or replays commits from one branch onto another base. Rewrites commit history — creates new commits with new SHAs. |
|
Interactive rebase | A rebase where you can pick, squash, reword, edit, drop, or reorder commits in a text editor. |
|
Cherry-pick | Apply the changes from one specific commit onto the current branch, creating a new commit with the same changes but a different SHA. |
|
Squash | Combining multiple commits into one. Done during interactive rebase ( |
|
Fixup | Like squash but automatically discards the fixup commit's message, keeping only the original commit's message. | Mark a commit with |
Amend | Modify the most recent commit — change the message, add files, or both. Creates a replacement commit (new SHA). |
|
Reflog | A log of where HEAD has been. Local to your machine, not pushed. The primary recovery tool for lost commits. |
|
Reachable | A commit is reachable if there is a chain of parent pointers from a named ref (branch, tag, HEAD) to it. | All commits on |
Unreachable | A commit with no ref pointing to it (directly or through its descendants). Unreachable objects are eventually garbage-collected. | Commits dropped by |
Garbage collection (GC) | Git's process of removing unreachable objects and repacking the object database for efficiency. |
|
File States
Term | Definition | Example |
|---|---|---|
Tracked | A file that Git knows about — it was previously staged and committed. Git monitors it for changes. | All files in a cloned repository are tracked. |
Untracked | A file in the working tree that Git has never seen. Not staged, not committed. | A newly created file before |
Ignored | A file excluded from Git tracking by a | Files matching |
Modified | A tracked file whose working tree content differs from the index. | An edited source file before |
Staged | A file whose changes have been added to the index, ready for the next commit. | A file after |
Clean | A working tree with no uncommitted changes — working tree matches HEAD. |
|
Dirty | A working tree with uncommitted changes (staged or unstaged). | After editing a file without committing. |
Conflict | A file with unresolved merge conflicts, marked with | Appears after a failed merge or rebase. |
Diff and Patch
Term | Definition | Example |
|---|---|---|
Diff | A representation of the changes between two versions of a file or set of files. Shows lines added (+) and removed (-). |
|
Hunk | A single contiguous block of changes within a diff. A file can have multiple hunks separated by unchanged context lines. |
|
Patch | A diff file that can be applied to recreate changes. Produced by |
|
Context lines | Unchanged lines surrounding a changed hunk in a diff. Provide context for the change. Default: 3 lines. |
|
Collaboration and Workflow
Term | Definition | Example |
|---|---|---|
Clone | A full local copy of a remote repository, including all history, branches, and tags. |
|
Fork | A server-side copy of a repository under your own account. You have write access to your fork, not the original. | Clicking "Fork" on GitHub creates a fork. |
Pull Request (PR) | A request to merge changes from one branch (or fork) into another. Provides a place for review and discussion. | Opening a PR on GitHub to merge |
Merge Request (MR) | GitLab's name for a pull request. | Same concept as a PR, different platform. |
Code review | The process of examining proposed changes before they are merged, for quality, correctness, and knowledge sharing. | A reviewer comments on and approves a PR. |
Hook | A script in |
|
Bare repository | A repository with no working tree — only the |
|
Shallow clone | A clone with a truncated history, fetching only the last N commits. Faster for CI pipelines. |
|
Sparse checkout | A mode where only a subset of the files in a commit are written to the working tree. |
|
LFS (Large File Storage) | A Git extension for storing large binary files outside the main repository. The repo stores pointers; actual files are on an LFS server. | Used for game assets, videos, large datasets. |
GPG signing | Using a GPG private key to cryptographically sign commits and tags, proving authorship. |
|
Submodule | A repository embedded within another repository at a specific commit. The parent repo stores only the submodule's URL and commit SHA. |
|
Subtree | A strategy for including another project's history inside your repository, without submodule complexity. |
|
Debugging
Term | Definition | Example |
|---|---|---|
Blame | A Git command that shows which commit last changed each line of a file, with author and date. |
|
Bisect | A binary search tool that helps find which commit introduced a bug. You mark commits as "good" or "bad" and Git narrows it down. |
|
Reflog expiry | Reflog entries are not kept forever. By default, reachable entries expire after 90 days; unreachable after 30 days. | Configure with |