Git Glossary: Essential Terms Every Developer Should Know
Git becomes much easier when its terminology is clear. Commands that initially seem unrelated—such as add, commit, switch, merge, fetch, and rebase—all operate on a small number of connected concepts.
This glossary explains those concepts in practical language. It is not only an alphabetical dictionary. The terms are grouped by how developers encounter them: repository structure, file states, history, branches, collaboration, integration, recovery, releases, and Git internals.
Each definition includes context, related commands, and common misunderstandings. Use the article as a reference while reading Git documentation, reviewing a pull request, debugging a repository, or learning an unfamiliar workflow.
How to Use This Git Glossary
You can read the glossary from beginning to end as a compact Git course, or jump to a specific category:
Version control and repository foundations.
Working tree, index, and file states.
Commits and history.
Branches and references.
Remote repositories and synchronization.
Merging, rebasing, and integration.
Undo, recovery, and temporary work.
Tags, releases, and verification.
Collaboration and hosting-platform terms.
Git internals and advanced concepts.
Git terms sometimes have both a general software-development meaning and a precise Git meaning. This article focuses on their meaning within Git.
Version Control and Repository Foundations
Version Control System
A version control system records changes to files over time so earlier states can be inspected or restored. It also supports collaboration by identifying changes, authors, and relationships between versions.
Git is a distributed version control system.
Distributed Version Control System
A distributed version control system gives each complete clone its own repository history rather than requiring every history operation to contact one central server.
With Git, developers can create commits, inspect history, create branches, and perform many merges locally.
Repository
A repository is a project managed by Git, including its files and version history.
A normal working repository contains:
The visible project files.
A hidden
.gitdirectory containing Git metadata and objects.
Common commands:
git init
git clone
git status
Local Repository
A local repository exists on the developer’s machine. It contains the commits, branches, tags, configuration, and other Git data available to that clone.
Creating a local commit does not automatically upload it anywhere.
Remote Repository
A remote repository is another Git repository that the local repository can communicate with. It is commonly hosted on GitHub, GitLab, Bitbucket, Azure Repos, or a private server.
A remote repository can be used for:
Collaboration.
Code review.
Shared history.
Backup of committed work.
CI/CD triggers.
Bare Repository
A bare repository contains Git repository data but normally has no checked-out working tree.
It is commonly used as a shared server-side repository.
Create one with:
git init --bare project.git
Working Tree
The working tree, also called the working directory, contains the files currently checked out and available for editing.
It can differ from both the staging area and the latest commit.
Working Directory
Working directory is commonly used as a synonym for working tree. Strictly speaking, a working directory can mean the current filesystem directory, but in everyday Git discussion it usually means the checked-out project files.
.git Directory
The .git directory stores the repository’s internal data, including objects, references, configuration, logs, and the index.
Deleting it removes the local Git history and turns the folder into an ordinary directory.
Clone
A clone is a new local repository created from an existing repository.
git clone https://example.com/team/project.git
A normal clone copies repository history, creates remote configuration, and checks out a working tree.
Initialize
To initialize a repository means creating Git metadata inside a directory.
git init
This creates a new local repository. It does not create a remote repository or upload files.
Working Tree, Index, and File States
Index
The index is Git’s proposed snapshot for the next commit. It is commonly called the staging area.
When a file is staged, Git records its current content in the index.
Staging Area
The staging area is the preparation layer between the working tree and the next commit.
The basic flow is:
Working Tree
|
| git add
v
Staging Area / Index
|
| git commit
v
Repository History
Stage
To stage a change means placing its current content into the index so it can be included in the next commit.
git add app.php
Staging a file does not create a commit.
Tracked File
A tracked file is known to Git through the index or repository history.
A tracked file can be:
Unchanged.
Modified.
Staged.
Deleted.
Untracked File
An untracked file exists in the working tree but has not been added to the index or committed.
Short status displays it as:
?? filename.txt
Modified File
A modified file is a tracked file whose working-tree content differs from the version in the index.
Staged File
A staged file has index content that differs from the current commit.
It is prepared for inclusion in the next commit.
Committed File
Committed means a selected version of the file is recorded in repository history.
The same file can later be modified again while the committed version remains preserved.
Ignored File
An ignored file is an untracked path matching an ignore rule.
Ignore rules may come from:
A repository
.gitignore.Nested ignore files.
A global excludes file.
Repository-specific exclude configuration.
.gitignore
A .gitignore file defines patterns for untracked files that Git should normally ignore.
Example:
.env
*.log
node_modules/
vendor/
dist/
It does not stop tracking files already committed.
.gitattributes
A .gitattributes file defines repository-level behavior for matching paths.
It can control:
Text and binary classification.
Line endings.
Diff drivers.
Merge drivers.
Export behavior.
Git LFS patterns.
Pathspec
A pathspec tells Git which paths a command should operate on.
Examples:
git add src/
git log -- README.md
git diff -- "*.php"
Pathspecs can support patterns and special syntax beyond ordinary shell paths.
Hunk
A hunk is a section of related changed lines shown in a diff.
Interactive staging allows individual hunks to be selected:
git add -p
Partial Staging
Partial staging means staging only some changes from a file rather than its entire working-tree version.
It is useful when one file contains several logical changes.
Clean Working Tree
A working tree is clean when the working files and index have no reportable changes relative to the current commit.
Typical status:
nothing to commit, working tree clean
Dirty Working Tree
A dirty working tree contains modified, staged, deleted, or relevant untracked files.
Dirty does not mean damaged. It simply means the current state differs from the current committed snapshot.
Commits and Project History
Commit
A commit is a recorded point in Git history. It contains a reference to a project snapshot, metadata, a message, and one or more parent relationships.
Create one with:
git commit -m "Add task search validation"
Commit Object
A commit object is Git’s internal object representing a commit.
It contains:
A tree reference.
Parent commit references.
Author information.
Committer information.
A commit message.
Commit Hash
A commit hash is the object identifier used to identify a commit.
It may be displayed in full or abbreviated form:
8f31d97
The exact identifier depends on repository object format and commit content.
Object ID
An object ID identifies a Git object such as a commit, tree, blob, or annotated tag.
It is often abbreviated as OID.
Snapshot
A snapshot is the complete project state represented by a commit.
Git stores content efficiently, so unchanged data can be reused rather than duplicated unnecessarily.
Parent Commit
A parent commit is a previous commit referenced by a commit.
A normal commit usually has one parent. The initial commit has no parent. A merge commit can have two or more parents.
Root Commit
A root commit is a commit without a parent. It begins a history line.
A normal repository usually has one root commit, though unusual histories can contain more than one.
Merge Commit
A merge commit is a commit with multiple parents, normally created when combining divergent histories.
It records both the merged snapshot and the relationship between the histories.
Author
The author is the person who originally created the change represented by a commit.
Committer
The committer is the person who recorded the current form of the commit in history.
Author and committer are often the same, but they can differ after patch application, cherry-picking, or rebasing.
Commit Message
A commit message explains the purpose and context of a commit.
It commonly contains:
A concise subject.
An optional explanatory body.
Optional structured trailers.
Trailer
A trailer is structured metadata placed near the end of a commit message.
Examples:
Signed-off-by: Jane Developer <jane@example.com>
Reviewed-by: Alex Maintainer <alex@example.com>
Fixes: #142
Revision
A revision is a name or expression referring to a commit or set of commits, depending on the command.
Examples:
HEAD
main
v1.0.0
HEAD~2
main..feature/search
History
Git history is the graph of commits and their parent relationships.
Inspect it with:
git log --oneline --graph --decorate --all
Reachable Commit
A commit is reachable from a reference when Git can follow parent links from that reference to the commit.
Reachability determines which commits appear in many log and range operations.
Unreachable Commit
An unreachable commit is not reachable from ordinary references such as branches or tags.
It may still exist temporarily and can sometimes be found through reflogs or object inspection before cleanup removes it.
Commit Graph
The commit graph is the directed history structure formed by commits and their parent relationships.
It is not determined only by timestamps.
First Parent
The first parent of a commit is the primary parent recorded first.
For a merge commit, first-parent history commonly follows the branch that received the merge.
git log --first-parent
Ancestor
A commit is an ancestor of another when it is reachable by following parent links backward from the later commit.
Descendant
A commit is a descendant of another when the older commit is reachable from it through parent relationships.
References, Branches, and HEAD
Reference
A reference, often shortened to ref, is a name pointing to an object ID.
Branches and tags are common references.
Ref
Ref is the common shorthand for reference.
Examples of full reference names:
refs/heads/main
refs/tags/v1.0.0
refs/remotes/origin/main
Branch
A branch is a movable reference used to identify a line of development.
When a commit is created on the current branch, the branch normally moves to the new commit.
Local Branch
A local branch is a branch in the local repository that can be checked out and updated by local commits.
Examples:
main
feature/task-search
fix/payment-timeout
Remote-Tracking Branch
A remote-tracking branch records the local repository’s latest known state of a branch in a remote repository.
Example:
origin/main
It is updated by fetch operations, not by ordinary local commits.
Default Branch
The default branch is the branch selected by default by a repository hosting platform or clone operation.
It is commonly named main, but the name is configurable.
Feature Branch
A feature branch is a temporary branch used to develop one feature or logical change.
It is usually reviewed, merged, and deleted after integration.
Release Branch
A release branch is used to prepare or maintain a release line.
Its exact role depends on the project workflow. It may be temporary for stabilization or long-lived for supported versions.
Hotfix Branch
A hotfix branch is used for an urgent repair based on the production or released code line.
Topic Branch
A topic branch is a general term for a short-lived branch containing one conceptual change, such as a feature, fix, or experiment.
HEAD
HEAD identifies the currently checked-out location.
Normally it points symbolically to the current branch:
HEAD -> main -> commit
Symbolic Reference
A symbolic reference points to another reference instead of directly to an object ID.
HEAD commonly acts as a symbolic reference to the current branch.
Detached HEAD
Detached HEAD means HEAD points directly to a commit rather than a branch.
This is useful for inspecting historical versions, but new commits should be preserved by creating a branch.
git switch --detach v1.0.0
git switch -c support/1.0
Branch Tip
The branch tip is the commit currently referenced by a branch.
Upstream Branch
An upstream branch is a branch configured as the related branch for a local branch.
It supports ahead/behind reporting and defaults for synchronization commands.
Tracking Branch
A tracking branch is a local branch configured with an upstream branch.
Do not confuse it with a remote-tracking branch.
Ahead
A local branch is ahead of its upstream when it has commits the upstream does not contain.
Behind
A local branch is behind its upstream when the upstream has commits not contained locally.
Diverged
Branches have diverged when each side contains commits the other does not contain.
Revision Syntax and Commit Selection
HEAD^
HEAD^ normally refers to the first parent of HEAD.
For a merge commit:
HEAD^1
HEAD^2
select different parents.
HEAD~n
HEAD~n follows the first-parent relationship n times.
HEAD~3
means three first-parent steps before HEAD.
Two-Dot Range
For revision-walking commands, A..B generally selects commits reachable from B but not from A.
git log main..feature/search
Three-Dot Range
For git log, A...B selects commits reachable from either side but not both.
For git diff, three-dot syntax compares the merge base with the right-side revision.
Merge Base
A merge base is a best common ancestor of two commits.
git merge-base main feature/search
It is commonly used to identify where branches diverged.
Peeling a Tag
Peeling means following an annotated tag object to the object it references.
git rev-parse v1.0.0^{}
git rev-parse v1.0.0^{commit}
Reflog Selector
A reflog selector refers to a previous recorded position of a reference.
HEAD@{1}
main@{yesterday}
Availability depends on local reflog history.
Remote Repositories and Synchronization
Remote
A remote is a configured name and URL representing another repository.
List remotes:
git remote -v
origin
origin is the conventional default name assigned to the repository cloned from.
It is not a special server type and can be renamed.
upstream
upstream is a common remote name for the official repository when origin points to a personal fork.
It is a convention, not a built-in requirement.
Remote URL
A remote URL tells Git how to contact another repository.
Common forms include:
https://example.com/team/project.git
git@example.com:team/project.git
ssh://git@example.com/team/project.git
Fetch
Fetch downloads objects and updates remote-tracking references without automatically integrating them into the current branch.
git fetch origin
Pull
Pull fetches remote changes and then integrates them according to configuration and options.
Integration may use merge, rebase, or fast-forward-only behavior.
git pull --ff-only
Push
Push sends objects and updates references in a remote repository.
git push origin main
A push may be rejected when it would overwrite newer remote history.
Refspec
A refspec describes how references map between local and remote repositories.
Example:
refs/heads/main:refs/heads/main
Refspecs are used by fetch and push operations.
Fast-Forward Push
A push is fast-forward when the new remote branch tip is a descendant of the existing remote tip.
No remote commits are removed from the branch history.
Non-Fast-Forward Push
A non-fast-forward push would replace the remote branch tip with a commit that does not contain the existing tip.
It is normally rejected unless force behavior is used.
Force Push
A force push updates a remote reference even when normal fast-forward safety fails.
git push --force
It can overwrite shared history.
Force with Lease
--force-with-lease performs a force update only when the remote reference still matches the state the local repository expects.
git push --force-with-lease
It is safer than a blind force push but still rewrites remote history.
Prune
Pruning removes stale remote-tracking references whose corresponding remote branches no longer exist.
git fetch --prune
Fork
A fork is a server-side copy of a repository under another account or namespace, typically created through a hosting platform.
It is commonly used for external contributions.
Mirror
A mirror is a repository intended to reproduce references from another repository comprehensively.
Mirror clone and push operations are more extensive than ordinary branch synchronization.
Merging and Integration
Merge
A merge combines development histories into the current branch.
git switch main
git merge feature/search
Fast-Forward Merge
A fast-forward merge occurs when the current branch can move directly to the other branch tip because no divergent current-branch commits need combining.
Three-Way Merge
A three-way merge combines:
The current branch tip.
The other branch tip.
Their merge base.
It normally creates a merge commit when histories diverged.
Merge Conflict
A merge conflict occurs when Git cannot automatically determine a safe combined result.
Developers must resolve the intended content and stage the result.
Conflict Marker
Conflict markers identify competing text sections:
<<<<<<< HEAD
Current branch content
=======
Incoming branch content
>>>>>>> feature/search
They must be removed during resolution.
Ours
During a normal merge, ours means the current branch side.
Theirs
During a normal merge, theirs means the branch being merged.
The perspective can be less intuitive in rebasing operations, so always inspect the current operation.
Merge Strategy
A merge strategy is the high-level algorithm Git uses to combine histories.
It can be selected with:
git merge -s <strategy>
Strategy Option
A strategy option modifies behavior within a selected merge strategy.
git merge -Xours feature/search
-Xours is not the same as the separate ours merge strategy.
Octopus Merge
An octopus merge combines more than two heads in one merge commit.
It is normally used for independent, non-conflicting topics.
Squash Merge
A squash merge combines the net changes from a branch into one new commit on the target branch.
It does not preserve the original branch’s parent relationship as a normal merge commit would.
Rebase
Rebase replays commits onto a new base, creating replacement commits.
git rebase main
It can create a linear history but rewrites commit IDs.
Interactive Rebase
Interactive rebase allows selected commits to be reordered, edited, combined, reworded, or removed.
git rebase -i HEAD~5
Squash
To squash commits means combining several commits into one.
This can happen through interactive rebase or a hosting-platform squash merge.
Fixup Commit
A fixup commit is intended to be combined automatically with an earlier commit during an autosquash rebase.
git commit --fixup=<commit>
Autosquash
Autosquash rearranges recognized fixup! and squash! commits next to their targets during interactive rebase.
git rebase -i --autosquash main
Cherry-Pick
Cherry-pick applies the change introduced by an existing commit onto the current branch as a new commit.
git cherry-pick abc1234
It is commonly used for backports and selected fixes.
Backport
A backport applies a newer fix or feature to an older maintained release line.
Cherry-pick is often used, followed by testing against the older environment.
Revert
Revert creates a new commit that reverses the changes introduced by another commit.
git revert abc1234
It is appropriate for undoing shared history without deleting the original commit.
Undo, Recovery, and Temporary Work
Restore
git restore updates working-tree or index content from another source.
Examples:
git restore file.txt
git restore --staged file.txt
The first can discard unstaged work. The second unstages changes while keeping the working file.
Reset
Reset moves a branch reference and can also update the index and working tree, depending on mode.
Soft Reset
A soft reset moves the branch while preserving index and working-tree content.
git reset --soft HEAD~1
Mixed Reset
A mixed reset moves the branch and resets the index while preserving working-tree changes.
It is the default reset mode.
Hard Reset
A hard reset moves the branch and resets both index and working tree.
git reset --hard HEAD~1
It can destroy uncommitted work.
Stash
A stash temporarily stores selected local changes and normally restores a cleaner working state.
git stash push -m "WIP: task search"
Stash Entry
A stash entry is one saved stash state identified through the stash reflog:
stash@{0}
Apply
Applying a stash restores its changes while keeping the stash entry.
git stash apply
Pop
Popping a stash applies it and removes it after successful application.
git stash pop
Drop
Dropping a stash removes one stash entry.
git stash drop stash@{1}
Clear
Clearing stashes removes all stash entries.
git stash clear
Reflog
A reflog records local updates to references such as HEAD and branch tips.
git reflog
It can help recover commits after reset, rebase, amend, branch deletion, or detached work.
Recovery Branch
A recovery branch is a new branch created to preserve a commit found through reflog or object inspection.
git branch recovery HEAD@{2}
Clean
git clean removes untracked files.
Preview first:
git clean -nd
Delete untracked files and directories:
git clean -fd
This can permanently remove local files not stored elsewhere.
Amend
Amend replaces the latest commit with a new commit containing updated content or metadata.
git commit --amend
The commit ID changes.
Tags, Releases, and Verification
Tag
A tag is a reference used to give a stable name to an object, usually a commit.
Tags commonly identify releases and milestones.
Lightweight Tag
A lightweight tag points directly to an object.
git tag v1.0.0
It has no separate tag message or tagger metadata.
Annotated Tag
An annotated tag creates a tag object containing a tagger, date, message, and optional signature.
git tag -a v1.0.0 -m "Release version 1.0.0"
Signed Tag
A signed tag is an annotated tag carrying a cryptographic signature.
git tag -s v1.0.0 -m "Release version 1.0.0"
Release Tag
A release tag is a project convention using a tag to identify a released commit.
Git does not enforce version meaning.
Semantic Versioning
Semantic Versioning is a version naming convention based on:
MAJOR.MINOR.PATCH
It is frequently used in tag names such as v2.4.1, but it is not built into Git.
Describe
git describe creates a human-readable name for a commit based on a nearby tag.
git describe --tags --always
Verification
Verification checks a signature or object relationship.
Examples:
git verify-tag v1.0.0
git verify-commit abc1234
Signed Commit
A signed commit contains a cryptographic signature associated with the commit object.
Sign-Off
A sign-off is a textual Signed-off-by trailer added to a commit message.
git commit --signoff
It is not the same as cryptographic signing.
Collaboration and Hosting-Platform Terms
Pull Request
A pull request is a hosting-platform collaboration feature proposing that changes be reviewed and merged into another branch.
It is not a native Git object.
Merge Request
A merge request is GitLab’s common term for a review-and-integration proposal. It is conceptually similar to a pull request.
Code Review
Code review is the process of inspecting and discussing proposed changes before integration.
It may include:
Inline comments.
Design feedback.
Testing review.
Security analysis.
Approval decisions.
Reviewer
A reviewer is a person asked to evaluate proposed changes.
Approval
An approval is a hosting-platform review state indicating that a reviewer accepts the proposed change according to project policy.
Draft Pull Request
A draft pull request exposes work for discussion and CI before it is ready to merge.
Protected Branch
A protected branch is controlled by hosting-platform rules that may restrict direct pushes, force pushes, deletion, or merging.
Required Check
A required check is an automated result that must succeed before integration.
Status Check
A status check reports the result of automated validation associated with a commit or pull request.
CI
Continuous Integration automatically validates frequently integrated changes through builds, tests, analysis, and related checks.
CD
CD can mean Continuous Delivery or Continuous Deployment.
Continuous Delivery: Software remains ready for release, with deployment possibly requiring approval.
Continuous Deployment: Accepted changes are deployed automatically.
Pipeline
A pipeline is an automated sequence of jobs such as testing, building, packaging, scanning, and deploying.
Workflow
A Git workflow is the team’s process for branches, commits, review, integration, releases, and maintenance.
A platform automation workflow is a configured automated process. Context determines the meaning.
GitHub Flow
GitHub Flow is a lightweight workflow based on a protected default branch, short-lived branches, pull requests, review, checks, and frequent integration.
Git Flow
Git Flow is a release-oriented branching model using long-lived main and develop branches plus feature, release, and hotfix branches.
Trunk-Based Development
Trunk-based development emphasizes frequent integration into one main branch, often using very short-lived branches and feature flags.
Forking Workflow
The Forking Workflow gives each contributor a personal server-side fork and uses pull requests into the official repository.
CODEOWNERS
CODEOWNERS is a hosting-platform convention assigning review responsibility for selected paths.
It is not part of core Git behavior.
Diff, Inspection, and Debugging Terms
Diff
A diff describes differences between two states.
Examples:
git diff
git diff --staged
git diff v1.0.0 v1.1.0
Patch
A patch is a textual representation of changes that can be reviewed or applied.
Unified Diff
A unified diff is the common patch format showing context lines and additions or deletions.
Additions begin with +; deletions begin with -.
Context Line
A context line is an unchanged line shown around changed lines to make the patch understandable and applicable.
Blame
git blame annotates lines with the commits that last changed them.
git blame app.php
It should be used to investigate context, not assign personal fault.
Pickaxe Search
A pickaxe search finds commits based on content changes.
Exact string count changes:
git log -S"functionName" -p
Changed lines matching a regular expression:
git log -G"function.*Name" -p
Bisect
git bisect performs a binary search through commits to identify the first commit where behavior became bad.
Good Commit
During bisect, a good commit is known not to contain the problem.
Bad Commit
During bisect, a bad commit is known to contain the problem.
Shortlog
git shortlog summarizes commits grouped by author.
Mailmap
A .mailmap file maps alternate names and email addresses to canonical contributor identities for reporting.
Range-Diff
git range-diff compares two versions of a commit series.
It is useful for reviewing how a patch series changed after rebasing or revision.
Git Internals
Object Database
The object database stores Git objects addressed by object IDs.
Common object types are:
Blob.
Tree.
Commit.
Tag.
Blob
A blob object stores file content.
It does not inherently store the filename. Filenames are associated through tree objects.
Tree
A tree object represents a directory-like snapshot that maps names to blobs or other trees.
Tag Object
A tag object stores annotated tag metadata and points to another object.
Content-Addressable Storage
Git stores objects using identifiers derived from their content and metadata representation.
Changing the object changes its ID.
Plumbing Command
A plumbing command exposes lower-level Git operations intended for scripts, tools, and internal workflows.
Examples include:
git cat-file
git hash-object
git update-index
git write-tree
git commit-tree
Porcelain Command
A porcelain command provides a higher-level user-facing interface.
Examples include:
git add
git commit
git switch
git merge
git status
Packfile
A packfile stores many Git objects in a compressed format for efficiency.
Loose Object
A loose object is stored individually rather than inside a packfile.
Garbage Collection
Garbage collection optimizes repository storage and may eventually remove unreachable objects.
git gc
Prune
In object maintenance, prune can mean removing unreachable objects that are old enough according to policy.
This differs from pruning stale remote-tracking references.
Index Entry
An index entry records path-related staged information, including mode, object ID, and stage number.
Index Stage
During a conflict, the index may contain multiple stages:
Stage 1: Merge base.
Stage 2: Ours.
Stage 3: Theirs.
Hooks
Hooks are programs invoked at defined points in Git operations.
Examples:
pre-commit.commit-msg.pre-push.post-merge.
Worktree
A Git worktree is an additional working tree attached to the same repository data.
git worktree add ../project-hotfix hotfix/login
It allows multiple branches to be checked out in separate directories without creating independent full clones.
Submodule
A submodule records another Git repository at a specific commit inside a parent repository.
It is useful when projects must remain independently versioned, but it adds synchronization and onboarding complexity.
Superproject
A superproject is a repository containing one or more submodules.
Shallow Clone
A shallow clone contains limited history, commonly created with:
git clone --depth=1 URL
Some history operations are limited until more history is fetched.
Partial Clone
A partial clone initially omits selected object content and retrieves it when required.
It is useful for large repositories.
Sparse Checkout
Sparse checkout limits which tracked paths appear in the working tree.
The repository can still know about paths that are not currently checked out.
Git LFS
Git Large File Storage is an extension that stores small pointer files in Git while large content is stored separately.
It is useful for large binary assets but requires server and client support.
Command-Line and Configuration Terms
Option
An option changes command behavior.
Examples:
--staged
--oneline
--all
-p
Argument
An argument is a value supplied to a command, such as a branch, commit, remote, or path.
git show v1.0.0
v1.0.0 is an argument.
Double Dash
-- commonly separates options or revisions from paths.
git log -- README.md
git diff HEAD~1 HEAD -- src/
Configuration Scope
Git configuration can exist at several scopes:
System.
Global.
Local repository.
Worktree.
Command invocation.
More specific applicable settings normally override broader ones.
Global Configuration
Global configuration provides defaults for the current operating-system user.
git config --global user.name "Jane Developer"
Local Configuration
Local configuration applies to one repository and is normally stored in .git/config.
Alias
An alias creates a shorter name for a Git command or command sequence.
git config --global alias.lg "log --graph --decorate --oneline --all"
Credential Helper
A credential helper stores, retrieves, caches, or manages authentication credentials for Git remote operations.
Commit identity settings are not authentication credentials.
Pager
A pager displays long output one screen at a time.
Commands such as git log commonly use one.
Press q to quit in common pager environments.
Diff Driver
A diff driver customizes how Git compares selected file types.
Merge Driver
A merge driver customizes how selected paths are merged.
Clean Filter
A clean filter transforms content when it enters Git’s object storage through the index.
Smudge Filter
A smudge filter transforms content when it is written into the working tree.
Git LFS uses filter mechanisms as part of its operation.
Frequently Confused Git Terms
Git vs GitHub
Git is the version control system. GitHub is a hosting and collaboration platform built around Git repositories.
Stage vs Commit
Stage prepares content in the index. Commit records the staged snapshot in history.
Fetch vs Pull
Fetch downloads remote information without integrating it. Pull fetches and then integrates according to selected behavior.
Pull vs Push
Pull brings remote changes toward the local repository. Push sends local changes toward a remote repository.
Branch vs Tag
A branch moves as new commits are created. A tag normally remains fixed at one object.
Local Branch vs Remote-Tracking Branch
A local branch is used for local development. A remote-tracking branch records the last fetched state of a remote branch.
Upstream Branch vs upstream Remote
An upstream branch is tracking configuration for a local branch. A remote named upstream is a naming convention commonly used in fork workflows.
Merge vs Rebase
Merge combines existing histories and may create a multi-parent commit. Rebase replays commits and creates replacements.
Revert vs Reset
Revert creates a new undo commit. Reset moves a branch and can alter the index and working tree.
Restore vs Reset
Restore focuses on file content in the working tree or index. Reset can move references and update repository layers.
Apply vs Pop
Stash apply restores changes and keeps the stash. Pop restores and removes it after success.
Sign-Off vs Signature
A sign-off is a message trailer. A signature is cryptographic data attached to a commit or annotated tag.
Commit Hash vs Branch Name
A commit hash identifies one object. A branch name is a movable reference that can point to different commits over time.
Working Tree vs Repository
The working tree is the visible checked-out files. The repository includes Git history, objects, and references.
Ignored vs Untracked
Ignored files are untracked paths matched by ignore rules. Not every untracked file is ignored.
Merge Conflict vs Failed Merge
A conflict means Git needs a human decision for selected paths. The merge operation can continue after resolution or be aborted.
Practical Git Vocabulary Example
Consider this workflow:
git clone https://example.com/team/project.git
git switch -c feature/task-search
# Edit files
git status
git add -p
git commit -m "Add task keyword matching"
git fetch origin
git rebase origin/main
git push -u origin feature/task-search
The vocabulary is:
Clone: Creates a local repository from a remote repository.
Remote: The server-side repository named
origin.Branch:
feature/task-searchis a movable local reference.Working tree: The edited project files.
Status: A report of tracked, untracked, staged, and modified paths.
Partial staging:
git add -pselects hunks.Commit: Records the staged snapshot.
Fetch: Updates remote-tracking information.
Rebase: Replays feature commits on the updated remote base.
Push: Publishes the local branch.
Upstream:
-uconfigures the remote branch relationship.
Essential Terms Checklist
A beginner should be able to explain:
Repository.
Working tree.
Index or staging area.
Tracked and untracked files.
Commit.
Branch.
HEAD.Remote.
Fetch, pull, and push.
Merge and conflict.
Tag.
Stash.
Revert and reset.
An intermediate Git user should also understand:
Upstream branches.
Remote-tracking branches.
Revision ranges.
Merge bases.
Rebase and cherry-pick.
Reflog.
Annotated tags.
Force-with-lease.
Interactive staging and rebase.
An advanced user should understand:
Object types.
Reference namespaces.
Index stages.
Refspecs.
Reachability.
Plumbing commands.
Packfiles and maintenance.
Partial clone and sparse checkout.
Submodules and worktrees.
Frequently Asked Questions
Is a Commit the Same as a File Version?
No. A commit represents a project snapshot and metadata, not only one file.
Is a Branch a Copy of the Project?
No. A branch is a movable reference to a commit. The working tree changes when branches are switched.
Is origin Always GitHub?
No. origin is only a conventional remote name and can point to any compatible Git repository.
Does git add Upload a File?
No. It stages the file locally. Uploading committed objects requires a push.
Does git pull Mean Download?
It downloads through fetch and then performs an integration step. Use git fetch when you want to download without immediate integration.
Is HEAD the Latest Commit in the Entire Repository?
No. HEAD identifies the currently checked-out location. Another branch may contain newer or different commits.
Are Commit IDs Permanent?
An existing commit object keeps its ID, but rebasing, amending, and cherry-picking create new commits with new IDs.
Does Deleting a Branch Delete Its Commits?
It removes the branch reference. Commits remain while reachable from other references and may remain recoverable temporarily through reflogs.
Is a Pull Request Part of Git?
No. It is a feature provided by repository hosting platforms.
Is a Tag a Release?
A tag is a Git reference. A project may use it to identify a release, while a hosting platform can add release notes and downloadable assets.
Is Reflog Shared with the Remote?
No. Reflogs are local to each repository clone.
Is a Merge Conflict a Repository Error?
No. It means Git cannot choose the intended combined content automatically.
Why Are There So Many Terms for the Staging Area?
Staging area is the user-facing concept. Index is the traditional technical term. Both usually refer to the proposed next snapshot.
Conclusion
Git terminology describes one connected model. The working tree contains current files, the index contains the proposed next snapshot, and commits form the repository history. Branches and tags name points in that history, while HEAD identifies the current location.
Remotes allow repositories to exchange objects and references through fetch, pull, and push. Merging, rebasing, cherry-picking, and reverting change how histories relate. Stash and reflog help manage temporary work and recover local history. Hosting platforms add pull requests, reviews, protections, and CI/CD around core Git behavior.
The most important terms to master first are repository, working tree, index, commit, branch, HEAD, remote, merge, and tag. Once those concepts are clear, advanced commands become easier because they are simply different operations on the same objects, snapshots, and references.
This glossary completes the Git foundation series. The next natural step is a dedicated GitHub series covering remote repository creation, HTTPS and SSH authentication, cloning, pushing, forks, pull requests, issues, releases, branch protection, team permissions, and GitHub Actions.
Official References and Further Reading
