The Complete Git and Version Control Guide 2026: Every Command, Strategy, and Workflow Explained

A directory containing all project files and the complete Git history. Includes a .git directory with objects, refs, HEAD, config, and hooks. Can be local (on your machine) or remote (on a server like GitHub). A bare repository has no working tree, only the .git contents.

A snapshot of the repository at a specific point in time. Contains a tree object (directory listing), parent commit(s), author, committer, timestamp, and message. Identified by a SHA-1 hash. Commits are immutable: you cannot change a commit, only create new ones.

A lightweight, movable pointer to a commit. The default branch is usually "main" (formerly "master"). Creating a branch is just creating a new pointer; it does not copy files. When you commit on a branch, the pointer advances to the new commit. Branches enable parallel development.

A symbolic reference that points to the current branch (or directly to a commit in "detached HEAD" state). HEAD determines which commit your working directory reflects. git log HEAD shows the current branch history. Detached HEAD occurs when you checkout a specific commit rather than a branch.

The directory of files you see and edit. It reflects the state of the current branch (HEAD) plus any uncommitted changes. Files in the working tree can be: tracked (known to Git), untracked (new files not yet added), or ignored (matched by .gitignore).

An intermediate area between the working tree and the repository. "git add" stages changes from the working tree to the index. "git commit" records the index as a new commit. The staging area lets you compose commits precisely, including only the changes you want.

A reference to another copy of the repository, usually on a server. The default remote is named "origin". Remotes have URLs (HTTPS or SSH) and tracking branches (origin/main). "git fetch" downloads from remotes; "git push" uploads to remotes. A repository can have multiple remotes.

Combining two branches by creating a merge commit with two parents. Fast-forward merge simply moves the branch pointer when no divergence exists. Three-way merge creates a new commit when both branches have new commits. Merge commits preserve the complete branch history.

Moving a sequence of commits to a new base commit, rewriting history. Interactive rebase (git rebase -i) lets you edit, squash, reorder, or drop commits. Rebase creates a linear history (no merge commits). Never rebase commits that have been pushed to shared branches.

Applying the changes introduced by one or more specific commits onto the current branch. Creates new commits with the same changes but different SHA-1 hashes. Used for backporting fixes to release branches or selectively applying changes.

A temporary storage for uncommitted changes. "git stash" saves your working directory and index state, reverting to a clean state. "git stash pop" reapplies the stashed changes. Stash is a stack: multiple stashes can be saved and applied individually.

A named reference to a specific commit, used for marking release points (v1.0.0, v2.3.1). Lightweight tags are just pointers. Annotated tags are full objects with metadata (tagger, date, message, optional GPG signature). Use annotated tags for releases.

A Git object storing file contents. Blobs are content-addressed: the same content always produces the same SHA-1 hash. Blobs store raw file data without the filename; the filename is stored in the tree object. This is why renaming a file without changing content creates no new blob.

A Git object representing a directory. Contains entries mapping filenames to blob hashes (files) or other tree hashes (subdirectories), along with mode bits (permissions). Each commit points to a root tree object representing the complete state of all files.

The fundamental storage unit in Git. Four types: blob (file contents), tree (directory listing), commit (snapshot with metadata), and tag (named reference with metadata). All objects are identified by their SHA-1 hash and stored in .git/objects.

A compressed file containing multiple Git objects for efficient storage and transfer. Git periodically packs loose objects into pack files during "git gc". Pack files use delta compression: similar objects are stored as differences from a base object, dramatically reducing repository size.

A human-readable name pointing to a commit SHA-1 hash. Branches are refs in .git/refs/heads/. Tags are refs in .git/refs/tags/. Remote tracking branches are in .git/refs/remotes/. HEAD is a symbolic ref. Refs make it possible to use names like "main" instead of 40-character hashes.

A log of all changes to HEAD and branch tips, stored locally. Records every checkout, commit, merge, rebase, and reset. Essential for recovering "lost" commits after a reset or rebase. Entries expire after 90 days (configurable). Reflogs are local-only and not shared with remotes.

A merge where the target branch has no new commits since the source branch diverged. Git simply moves the branch pointer forward to the latest commit. No merge commit is created. Can be enforced with git merge --ff-only or prevented with git merge --no-ff.

A merge where both branches have diverged with new commits. Git finds the common ancestor (merge base), compares both branches changes against it, and creates a merge commit combining both sets of changes. Conflicts arise when both branches modify the same lines.

Occurs when Git cannot automatically combine changes from two branches because they modify the same lines of the same file differently. Conflicts must be resolved manually by editing the file, choosing the correct version, then staging and committing. Git marks conflicts with <<<<<<<, =======, and >>>>>>> markers.

A merge that combines all commits from a branch into a single commit on the target branch. "git merge --squash" stages the changes without committing, letting you create one clean commit. Loses the individual commit history of the branch but keeps the main branch clean.

A file specifying patterns of files and directories that Git should ignore. Untracked files matching .gitignore patterns are not shown in "git status" and not added by "git add". Supports glob patterns (*.log, build/, !important.log). Can be placed in any directory, affecting that directory and subdirectories.

Scripts that Git runs automatically before or after events (commit, push, merge, etc.). Client-side hooks: pre-commit, commit-msg, pre-push, post-merge. Server-side hooks: pre-receive, post-receive, update. Stored in .git/hooks/. Used for linting, testing, formatting, deployment, and notifications.

A Git repository embedded inside another Git repository. Used for including external dependencies or shared libraries. Each submodule is pinned to a specific commit. Submodules are registered in .gitmodules. Complex to manage: require explicit init, update, and sync commands.

A linked working directory for the same repository. "git worktree add <path> <branch>" creates a new working directory checked out to a different branch, sharing the same .git objects. Useful for working on multiple branches simultaneously without stashing or cloning.

An extension for versioning large files (binaries, media, datasets) by storing them on a separate server and keeping only lightweight pointers in the Git repository. Tracks files via "git lfs track". Reduces repo size and clone times. Supported by GitHub, GitLab, and Bitbucket.

A feature for checking out only a subset of files in a repository. Useful for monorepos where you only need certain directories. "git sparse-checkout set <dir>" configures which directories to include. Combined with partial clone (--filter=blob:none) for minimal disk usage.

A single Git repository containing multiple projects, services, or packages. Used by Google, Meta, Microsoft. Benefits: atomic cross-project changes, shared tooling, consistent versioning. Challenges: large repo size, slow git operations at scale. Tools: Nx, Turborepo, Bazel, Lerna.

An architecture where each project or service has its own Git repository. Benefits: clear ownership, independent versioning, smaller repos. Challenges: cross-repo changes require multiple PRs, dependency management complexity, version synchronization. Most common for microservices.

A mechanism for proposing changes from one branch to another, typically with code review. GitHub calls them "pull requests," GitLab calls them "merge requests." PRs enable discussion, automated checks, approval workflows, and documentation of why changes were made.

GitLab terminology for a pull request. Functionally identical: proposes merging one branch into another with code review, CI checks, and approval. MR is arguably more accurate than PR since the reviewer decides whether to merge, not pull.

A complete copy of a repository under a different owner/organization. Forking creates a server-side clone on platforms like GitHub. Changes are proposed from the fork to the original via pull requests. Standard workflow for open-source contributions. Forks can diverge permanently (hard fork).

The original repository that a fork was created from. Convention: "origin" = your fork, "upstream" = the original repo. git remote add upstream <url> adds a reference. git fetch upstream pulls changes from the original project for keeping your fork up to date.

A technique for deploying code to production with new features disabled. Code changes are merged to main but wrapped in conditional checks. Features are enabled for specific users, percentages, or environments via configuration. Essential for trunk-based development and gradual rollouts.

A specification for commit messages: type(scope): description. Types: feat, fix, docs, style, refactor, test, chore. Example: "feat(auth): add OAuth2 login". Enables automated changelog generation, semantic versioning, and commit categorization.

A versioning scheme: MAJOR.MINOR.PATCH (e.g., 2.4.1). MAJOR: breaking changes. MINOR: new features (backward compatible). PATCH: bug fixes. Pre-release: -alpha, -beta, -rc. Often automated from Conventional Commits. Used by npm, Cargo, and most package managers.

A commit cryptographically signed with a GPG or SSH key to verify the author identity. GitHub shows a "Verified" badge on signed commits. Some organizations require commit signing to prevent impersonation. Configure with git config commit.gpgSign true.

A secure cross-platform credential helper for Git. Stores HTTPS credentials (tokens, passwords) in the OS credential store (Keychain, Windows Credential Manager, GNOME Keyring). Eliminates the need to enter credentials repeatedly. Supports multi-factor authentication flows.

A clone with limited commit history. "git clone --depth 1" fetches only the latest commit, dramatically reducing clone time and disk usage. Useful for CI/CD where full history is not needed. Can be "unshallowed" later with "git fetch --unshallow".

A clone that defers downloading certain objects until they are needed. "--filter=blob:none" clones without file content (only trees and commits). Blobs are fetched on demand. Significantly reduces initial clone time for large repositories. Requires server support.

Reuse Recorded Resolution. When enabled (git config rerere.enabled true), Git remembers how you resolved merge conflicts and automatically applies the same resolution next time it encounters the same conflict. Extremely useful for long-lived branches that are repeatedly rebased.

A binary search through commit history to find the commit that introduced a bug. "git bisect start; git bisect bad; git bisect good <commit>" narrows down the offending commit in O(log n) steps. Can be automated: "git bisect run <test-script>" automatically tests each commit.

Shows the last commit that modified each line of a file. "git blame <file>" displays commit hash, author, date, and line content for every line. Use -w to ignore whitespace changes, -C to detect code moved between files. Essential for understanding why code was changed.

A file (CODEOWNERS or .github/CODEOWNERS) that defines which teams or individuals are responsible for code in specific directories or files. Used by GitHub and GitLab to automatically request reviews from code owners when files they own are modified in a pull request.

A branch with rules enforced by the hosting platform. Common rules: require pull request reviews, require status checks to pass, require signed commits, disallow force pushes, restrict who can push. Protects critical branches (main, release/*) from accidental or unauthorized changes.

The content-addressable storage system underlying Git. Every file, directory, and commit is stored as an object identified by its SHA-1 hash. Objects are immutable: creating a modified version produces a new object with a different hash. This model enables integrity verification and deduplication.

A storage optimization where Git stores similar objects as differences (deltas) from a base object rather than full copies. Applied during packing (git gc). Reduces repository size dramatically for files that change incrementally. Pack files contain a mix of full objects and deltas.

A Git tool (now built into Git) for managing very large repositories. Enables partial clone, sparse-checkout, background maintenance, and filesystem monitor integration. Originally developed by Microsoft for the Windows OS repository (the largest Git repo at 300 GB).