The Glossary of Git and GitHub

Fundamentals & Core Concepts

Repository (Repo) — A directory containing a project's complete version history and metadata, stored locally on your machine (local repo) or on a server (remote repo). It's the entire project plus all its Git history packed into a .git folder.

Commit — A snapshot of your project at a specific point in time, containing changes (additions, deletions, modifications) along with a unique hash, author info, timestamp, and a message describing what changed and why.

Branch — An independent line of development pointing to a specific commit, allowing multiple features or fixes to be developed in parallel without affecting the main codebase. The default branch is typically main or master.

HEAD — A reference to the currently checked-out commit, effectively a pointer saying "you are here." When you switch branches, HEAD moves to point to the latest commit on that branch.

Working Directory — The actual files on your disk that you edit. Changes here are "unstaged" until you explicitly tell Git to track them via git add.

Staging Area (Index) — An intermediate holding area between your working directory and the repository where you prepare exactly which changes to include in the next commit via git add.

Untracked Files — New files in your working directory that Git has never seen before and isn't monitoring yet; they won't be included in commits until explicitly added.

Diff — A representation of changes between two states (commits, branches, working directory vs. staging) showing lines added, removed, and modified line-by-line.

Collaboration & Remote Work

Remote Repository — A Git repository hosted on a server (GitHub, GitLab, Bitbucket) accessible by multiple developers, serving as the central source of truth for a project.

Origin — The default name for the remote repository you cloned from or pushed to; shorthand for the URL of the remote server.

Upstream — A convention where "upstream" refers to the authoritative remote repository (often on the main development server) and "origin" refers to your fork or personal remote.

Pull (Fetch + Merge) — Downloading commits from a remote branch and immediately integrating them into your current local branch, combining git fetch and git merge in one operation.

Fetch — Downloading commits and branches from a remote repository to your local machine without merging them into your working branch, letting you review changes before integrating.

Push — Uploading your local commits to a remote repository, making them available to other developers and backing them up on the server.

Clone — Creating a complete local copy of a remote repository including all branches and history, typically done once at the start of working on a project.

Fork — A complete copy of a repository under your own GitHub account, commonly used to contribute to open-source projects without write access to the original.

Pull Request (PR) — A GitHub feature proposing changes from one branch to another (often from a feature branch to main), enabling code review, discussion, and CI checks before merging.

Code Review — The process where team members examine proposed changes (via a PR), provide feedback, request changes, and approve or reject the merge, ensuring quality and knowledge sharing.

Merging & Conflict Resolution

Merge — Integrating changes from one branch into another, combining the histories of both branches. If no conflicting changes exist, Git performs an automatic merge.

Fast-Forward Merge — A merge where the current branch hasn't diverged from the branch being merged in, so Git simply moves the pointer forward without creating a new commit.

Merge Commit — A commit created during a merge (non-fast-forward) that explicitly records the combining of two branches, showing both parents in the commit history.

Merge Conflict — A situation where Git can't automatically merge changes because both branches modified the same lines, requiring manual resolution by choosing which changes to keep.

Conflict Markers — The special syntax (<<<<<<<, =======, >>>>>>>) Git inserts around conflicting sections to show what changes exist on each side, guiding manual resolution.

Rebase — An alternative to merging that replays your commits on top of another branch, creating a linear history; often preferred for feature branches to keep the log clean.

Interactive Rebase — A rebase where you can edit, reorder, squash, or drop commits during the replay, useful for cleaning up your branch history before merging.

Squash — Combining multiple commits into a single commit, typically done during an interactive rebase or by selecting "squash and merge" on a PR to simplify the project history.

Cherry-Pick — Applying a specific commit from one branch to another without merging the entire branch, useful for backporting fixes or selectively including changes.

History & Inspection

Log — The chronological record of all commits in the repository, showing each commit's hash, author, date, and message, viewable via git log.

Blame — A Git feature showing which commit last modified each line of a file, and by whom, useful for understanding when and why changes were made.

Reflog — A reference log recording all movements of HEAD, useful for recovering lost commits or undoing operations like resets, available via git reflog.

Tag — A named reference to a specific commit, typically used to mark release versions (e.g., v1.0.0), more stable than a branch which moves as commits are added.

Annotated Tag — A tag with additional metadata (tagger, date, message), stored as a full object in Git, more commonly used than lightweight tags in professional projects.

Lightweight Tag — A simple pointer to a commit with no extra metadata, stored only as a reference in the .git folder.

Stash — Temporarily saving uncommitted changes (staged and unstaged) so you can switch branches or work on something else, retrievable later via git stash pop.

Detached HEAD — A state where you've checked out a specific commit (not a branch), meaning HEAD points directly to a commit rather than through a branch reference; useful for inspection but risky for new work.

Undoing & Rewriting History

Reset — Moving the current branch pointer to a different commit, with options to preserve or discard working directory changes (--soft, --mixed, --hard).

Revert — Creating a new commit that undoes the changes of a previous commit, preserving history; preferred to reset in collaborative settings since it doesn't rewrite public history.

Amend — Modifying the most recent commit (its message, files, or both) before pushing, useful for correcting mistakes; should not be done on commits already pushed and shared.

Clean — Removing untracked files from the working directory, helpful for clearing up build artifacts or generated files not in .gitignore.

Discard Changes — Using git checkout or git restore to revert unstaged changes in the working directory back to the last committed version.

Orphan Branch — A branch with no commit history relative to other branches, created via git checkout --orphan, sometimes used for separate project documentation or deployment artifacts.

GitHub-Specific Features

Issue — A GitHub discussion board entry for reporting bugs, requesting features, or discussing improvements; can be linked to PRs and labeled for organization.

Milestone — A grouping of issues and PRs in GitHub, typically representing a release or sprint, used to track progress toward a specific goal.

Label — A tag applied to issues and PRs (e.g., bug, enhancement, documentation) to categorize and filter work.

Project Board — A Kanban-style view in GitHub for organizing issues and PRs into columns (To Do, In Progress, Done), useful for project management and workflow visualization.

GitHub Actions — GitHub's native CI/CD platform allowing you to automate workflows (testing, building, deploying) triggered by events like pushes or PRs.

Workflow — A GitHub Actions configuration file (in .github/workflows/) defining automated jobs to run on triggers; can include testing, linting, building, or deploying.

Branch Protection Rule — A GitHub setting requiring PR reviews, status checks, or other conditions before commits can be merged into a protected branch (typically main).

CODEOWNERS — A file in the repository designating which users or teams are responsible for specific code paths, automatically requesting their review on relevant PRs.

Release — A GitHub feature packaging a specific commit (usually tagged) as a downloadable snapshot with release notes, checksums, and artifacts.

Gist — GitHub's simpler note-taking feature for sharing code snippets or configuration without needing a full repository.

Workflows & Best Practices

Commit Message — A description accompanying each commit explaining what changed and why; good messages are brief (50 char subject), descriptive, and follow a convention like Conventional Commits.

Atomic Commit — A commit containing a single logical change—one feature, one fix, or one refactor—making history more readable and easier to bisect or revert if needed.

Feature Branch Workflow — A common practice where each feature or fix is developed on a separate branch and merged to main via a PR after review, keeping main stable and deployable.

Git Flow — A branching model using long-lived develop and main branches alongside short-lived feature, release, and hotfix branches; more complex but suited to scheduled releases.

GitHub Flow — A simpler branching model with just main and short-lived feature branches, requiring continuous integration and frequent deployments; popular in modern teams.

Squash and Merge — A GitHub PR merge option combining all commits on the branch into one before merging, keeping main history clean while preserving the full history in the PR.

Create a Merge Commit — The default GitHub merge option creating a merge commit that joins two branches explicitly, preserving the branch's full history.

Rebase and Merge — A GitHub merge option replaying PR commits on top of main without a merge commit, resulting in a linear history similar to rebasing locally.

Conventional Commits — A standard for commit messages with a structured format (type(scope): subject) like feat(auth): add login validation, enabling automatic changelog generation and semantic versioning.

Configuration & Setup

.gitignore — A file listing patterns (files, directories, file types) that Git should ignore, preventing build artifacts, dependencies, secrets, and temporary files from being committed.

.gitattributes — A file specifying how Git should handle line endings, diffs, and merges for certain file types, useful for cross-platform consistency (e.g., *.md text eol=lf).

SSH Key — A public/private key pair used to authenticate with remote repositories over SSH, more secure than HTTPS and widely used in Git workflows.

Personal Access Token (PAT) — GitHub's alternative to passwords for authentication, used in CI/CD or command-line tools; can be scoped to specific permissions and revoked individually.

Global Configuration — Git settings applied to all repositories on your machine (user name, email, default editor) set via git config --global, overridable per-repo.

Local Configuration — Repository-specific Git settings stored in .git/config, overriding global settings for that project.

Troubleshooting & Advanced Concepts

Bisect — A Git tool to find which commit introduced a bug by binary search through history, checking out commits halfway through a range and letting you mark them as good or bad.

Submodule — A way to include another Git repository as a dependency within your project, useful for shared libraries; has a learning curve and adds complexity.

Subtree — An alternative to submodules for including external code, merging a subdirectory from another repo into your own; simpler but less flexible.

Shallow Clone — Cloning only recent commit history (with git clone --depth N) to save bandwidth and time, but limiting your ability to interact with old commits.

Bare Repository — A repository without a working directory, typically used as a central server to push to and pull from; identifiable by its .git directory structure at the root.

Hook — A script automatically triggered by Git events (pre-commit, post-commit, pre-push) that can enforce policies, run tests, or format code; stored in .git/hooks/.

LFS (Large File Storage) — A GitHub extension for storing large binary files (videos, datasets, binaries) outside the main repository to keep clone times reasonable.

Dirty Repository — A repository with uncommitted changes in the working directory or staging area; a warning that unsaved work exists.

Collaboration Patterns

Pair Programming — Two developers working on the same code simultaneously, either via screen sharing or taking turns; commits are typically attributed to both via co-author trailers.

Code Ownership — Designating specific team members (via CODEOWNERS) as responsible for code areas, ensuring expertise and accountability; automates review assignments on PRs.

WIP (Work in Progress) PR — A PR marked as not ready for merge yet, useful for early feedback or discussion before full implementation; often marked with a [WIP] prefix or draft status.

Draft PR — A GitHub feature for marking a PR as preliminary, signaling it's not ready to merge and reducing reviewer notifications until you mark it as ready.

Code Review Comments — Feedback left on specific lines of a PR, with options to suggest changes, request clarification, or approve, enabling asynchronous discussion and improvements.

Auto-Merge — GitHub's automatic merge feature that merges a PR once all branch protection rules (reviews, checks) pass, reducing manual overhead on frequently-updated PRs.

Dependency Graph — GitHub's visualization of your project's dependencies and their versions, checking for security vulnerabilities and alerting you to outdated packages.

Security & Governance

GPG Signing — Cryptographically signing commits and tags with your GPG key, allowing others to verify commits genuinely came from you; shown as "Verified" on GitHub.

Commit Signing — The practice of signing commits, enhancing trust and preventing impersonation in open-source and regulated environments.

Branch Protection — GitHub settings preventing direct pushes to protected branches (like main), requiring PRs and passing status checks to merge, crucial for stability.

Status Checks — Automated checks (tests, linting, builds) that run on commits and PRs via CI/CD, gating merges until they pass.

Rulesets — GitHub's newer alternative to branch protection rules, offering more granular and flexible conditions for governing repository interactions.

Secret Scanning — GitHub's automated detection of accidentally-committed secrets (API keys, tokens, passwords), alerting you to revoke them immediately.

Dependabot — A GitHub tool automatically checking dependencies for security vulnerabilities and creating PRs with updates, keeping your supply chain secure.

Security Advisory — A GitHub feature for privately reporting and coordinating security vulnerabilities before public disclosure, with a grace period for patches.

*written with Claude Sonnet 5