Git Cheat Sheet

Git terminology from commit to rebase

97 terms

Branch Strategy: The team-wide approach to organizing source-control branches, including how long branches live, when they are merged, and how releases are cut. Branch strategy affects integration frequency, conflict rates, code review flow, and how easily teams can ship or hotfix changes.
Cherry-Pick: To select a specific commit from one branch and apply it onto another branch without merging the entire branch history. Beyond Git itself, the term is also used culturally to mean selectively pulling in only the parts of a change or argument that are convenient.
Codeberg: A community-oriented Git hosting platform built on open source tooling, often positioned as a more independent alternative to commercial developer platforms. It is especially visible in communities that care about openness, federation, or platform governance.
Code Review: Code Review is the systematic examination of source code by one or more developers other than the author, aimed at finding bugs, improving code quality, ensuring consistency with coding standards, and sharing knowledge across the team. In modern workflows, code review typically happens through pull
Commit: Commit in version control is a snapshot of all tracked files in a repository at a specific point in time, along with a message describing what changed and why. Each commit is identified by a unique hash (in Git, a SHA-1 or SHA-256 hash) and records the author, timestamp, parent commit(s), and the ex
Commit Convention: A standardized format for commit messages, such as Conventional Commits, used to make history easier to read and to support automation for changelogs, semantic releases, or policy enforcement. Commit conventions help large teams keep repository history machine-readable and human-parseable.
Commit Hash: The unique identifier assigned to a commit in Git, derived from the content and metadata of that commit. Commit hashes are used to trace builds, reproduce historical states, compare code versions, and anchor deployment records to an exact source revision.
Commit History: The ordered record of commits that shows how a codebase changed over time, including authorship, messages, and the content of each change. Commit history is invaluable for debugging, auditing, blame analysis, and understanding why a system evolved the way it did.
Commit Hook: A script that runs automatically before or after certain version-control actions such as commit, push, or merge. Commit hooks are commonly used to enforce formatting, run tests, validate messages, or block changes that violate project rules.
Commit Message: The text attached to a version control commit that summarizes what changed and often why. Good commit messages are a strong cultural norm in healthy engineering teams because they preserve intent, improve reviewability, and make history useful later.
Commit Squashing: Combining multiple commits into one, often to simplify history before merging a pull request.
Draft PR: A pull request marked as not yet ready for final review or merge, often used to share work in progress, get early feedback, or make progress visible sooner. In healthy teams, draft PRs reduce surprise and encourage earlier collaboration.
Feature Branch: A short-lived Git branch created from the main branch to develop a single feature or fix in isolation. Merged back via pull request after code review and CI checks pass. Keeps the main branch stable and enables parallel development by multiple team members.
Feature Branch Culture: The habits and norms a team has around developing work in separate feature branches before merging. Feature branch culture influences review timing, merge pain, visibility of work, and whether long-lived branches are treated as normal or dangerous.
Force Push: To overwrite remote Git history with local history using a forced update, usually after rebasing or rewriting commits. It is powerful and sometimes necessary, but dangerous on shared branches.
Fork: Fork in software development is a copy of a repository or codebase that diverges from the original to pursue independent development. On platforms like GitHub, forking is the standard way to contribute to open-source projects: a developer forks a repository to their own account, makes changes, and s
Fork Culture: The norms a community has around forking projects, customizing work independently, and handling divergence from an original source. In open-source culture fork culture can signal freedom and experimentation, or fragmentation and governance problems, depending on context.
Ghost Branch: A stale Git branch that still exists on the remote or in local tooling even though nobody is actively using or maintaining it. It often confuses release and review workflows.
Git: Git is a distributed version control system created by Linus Torvalds in 2005 to manage the development of the Linux kernel. Unlike centralized version control systems, every developer's working copy of the code is a complete repository with full history, enabling offline work and fast operations. G
Git Bisect: A Git command that performs a binary search through commit history to find the exact commit that introduced a bug. You mark a known-good commit and a known-bad commit, then Git checks out the midpoint for you to test. Finds the culprit in O(log n) steps — 1000 commits requires only ~10 checks.
Git Blame: A Git Blame is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions, a
Git Blame Culture: A team dynamic where version history is used primarily to assign fault instead of understand context and fix problems constructively.
Git Branch: A Git Branch is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions,
Git Cherry-Pick: A Git Cherry-Pick is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstracti
Git Clone: A Git Clone is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions, a
Git Commit: A Git Commit is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions,
Git Commit Message Art: The playful or obsessive craft of writing commit messages with unusual style, humor, formatting, or aesthetic consistency. In engineering slang, commit message art can be delightful or distracting depending on whether meaning survives the performance.
Git Config: A Git Config is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions,
Git Conflict: A Git Conflict is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions
Git Culture: The shared habits, expectations, and arguments a team has around using Git, including branching, rebasing, commit messages, reviews, and release flow. Git culture often says as much about a team's coordination style as it does about version control itself.
Git Diff: A Git Diff is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions, an
Git Flow: A Git Flow is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions, an
Git Flow Debate: Arguments over branching models such as Git Flow, trunk-based development, and simpler release strategies.
Git Force Push: A force push in Git, often spoken about with a tone that ranges from routine to taboo depending on the branch and the culture. In engineering slang, force-pushing shared history is one of the classic ways to start unnecessary drama.
Git Fork: A Git Fork is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions, an
Git Good: A pun on 'get good' used to tell someone, jokingly or sharply, to improve their Git skills. It usually comes up after merge mistakes, rebasing confusion, or force-push accidents.
Git Grep: A Git Grep is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions, an
Git Gud: A meme-spelling variant of 'Git Good,' used as a joking challenge to improve Git proficiency. It leans more internet-meme than literal instruction.
Git History: A Git History is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions,
Git Hook: A Git Hook is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions, an
GitHub Flow: A lightweight Git workflow centered on short-lived branches, pull requests, and frequent deployment from a main branch. In engineering culture, GitHub Flow is often chosen by teams that value simplicity and continuous delivery over heavier branch models.
GitLab Flow: A Git workflow associated with GitLab that blends ideas from feature branching, environment-based branching, and release management. In engineering culture, GitLab Flow is often chosen by teams that need more structure than GitHub Flow but less ceremony than some older branching models.
Git LFS: Git Large File Storage, an extension that stores large binaries outside normal Git history while keeping lightweight references in the repo.
Git Log: A Git Log is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions, and
Git Merge: A Git Merge is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions, a
GitOps: An operational framework where the desired state of infrastructure is declared in a Git repository, and automated processes continuously reconcile the actual state with the declared state. Git as the single source of truth for everything.
Git Protocol: The communication protocol or protocols used by Git to transfer repository data between clients and servers. In practical culture, discussions of the Git protocol usually arise around authentication, performance, hosting, or compatibility issues.
Git Pull: A Git Pull is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions, an
Git Push: A Git Push is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions, an
Git Push and Pray: A joking phrase for pushing code without real confidence and then waiting for CI, deployment, or reality to tell you what happens. In engineering slang, it implies local feedback loops are not doing enough to inspire trust.
Git Rebase: A Git operation that moves or replays commits from one branch onto another base, creating a linear history without merge commits. Interactive rebase (git rebase -i) allows squashing, reordering, and editing commits. Cleaner than merge but rewrites history — never rebase commits that have been pushed
Git Remote: A Git Remote is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions,
Git Reset: A Git Reset is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions, a
Git Stash: A Git command that temporarily shelves uncommitted changes (both staged and unstaged) so you can switch branches or pull updates with a clean working directory. Changes are stored on a stack and can be reapplied later with git stash pop. Essential for context-switching between tasks.
Git Submodule: A Git Submodule is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstraction
Git Tag: A Git Tag is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions, and
Git Worktree: A Git Worktree is a development concept used to shape how software is built, executed, or maintained in real systems. Developers rely on it to make code easier to reason about, integrate, and operate as projects grow. It usually matters most when teams need predictable behavior, clearer abstractions
Gollum Wiki: A simple Git-backed wiki system often used for lightweight documentation and knowledge sharing.
Iceberg Commit: A commit whose visible diff looks small, but whose implications, hidden dependencies, or downstream effects are much larger than they first appear. The term warns reviewers not to trust surface area alone.
LGTM Culture: A review culture where approvals are often reduced to quick 'looks good to me' responses, sometimes efficient and sometimes shallow.
Linus Torvalds: The creator of the Linux kernel and Git, and one of the most influential figures in open source software history. In tech culture his name is associated with large-scale distributed development, blunt communication, and the long arc of Linux governance.
Looks Good To Me: The full phrase behind the common review shorthand LGTM, meaning the reviewer sees no blocking issues in the proposed change. Depending on team culture, it can signal careful approval or very shallow review.
Merge Conflict: Merge Conflict occurs in version control when two branches have made competing changes to the same lines of a file, or when one branch deletes a file that the other branch modified, making it impossible for the system to automatically reconcile the differences. When Git encounters a merge conflict,
Merge Conflict Slang: Informal language and shared jokes about conflicting changes colliding during version-control workflows. In engineering slang, merge-conflict talk often reveals how much simultaneous churn and coordination pain a team is carrying.
Merge Hell: A painful state where branches have diverged so much that combining them creates a maze of conflicts, regressions, and uncertainty. It usually reflects large diffs or long-lived branches.
Monorepo: A version control strategy where multiple projects, packages, or services are stored in a single repository. Simplifies code sharing, atomic cross-project changes, and consistent tooling. Requires specialized tools (Nx, Turborepo, Bazel) for efficient builds. Used by Google, Meta, and many large org
Pre-Commit: A Git hook that runs automatically before a commit is finalized, typically executing linters, formatters, type checkers, or secret scanners to enforce code quality standards. Also refers to the popular framework (pre-commit.com) that manages such hooks via a YAML config.
Pre-commit Hook: A Git hook script that runs automatically before a commit is created. Commonly used to run linters, formatters, type checkers, and secret scanners on staged files. If the hook exits with a non-zero status, the commit is aborted. The pre-commit framework standardizes hook management across projects.
PR Merge Strategy: The policy a project uses for integrating pull requests, such as merge commits, squash merges, or rebases, and the reasoning behind when each is appropriate. Merge strategy affects history readability, bisectability, and contributor workflow.
Pull Request: A proposal to merge changes from one branch into another, creating a space for code review, discussion, and automated checks. GitHub calls them 'pull requests'; GitLab calls them 'merge requests.' The difference has started actual arguments.
Push to Main: To send commits directly to the main branch, either by policy, permission, or recklessness, without an intermediate merge flow. In many teams this is normal on small repos and forbidden on critical ones.
Rebase: A Git operation (git rebase) that replays the commits from one branch onto a new base commit, rewriting commit hashes to produce a linear history. Interactive rebase (git rebase -i) additionally allows squashing, reordering, editing, or dropping commits before they are reapplied.
Rebase and Pray: A joking phrase for rebasing a complex branch with low confidence and hoping the resulting history still behaves correctly. It usually implies hidden conflicts or semantic breakage the merge tool cannot detect.
Release Branch: A branch reserved for preparing, stabilizing, or maintaining a release line separately from ongoing feature development. In engineering culture, release branches help teams isolate fixes and reduce last-minute chaos before shipping.
Release Tag: A version tag in version control marking the exact commit associated with a release. In repository practice, release tags make it easy to trace distributed artifacts back to a specific source state.
Repo: Short for repository. A directory tracked by a version control system (almost always Git) that contains a project's source code, history, branches, and configuration. Used so universally that the full word 'repository' sounds oddly formal in conversation.
Repository: A data structure managed by a version control system that stores a project's complete file history, branches, tags, and metadata. In Git, this is the .git directory containing the object database of commits, trees, and blobs that represent every recorded state of the project.
Reverted: Rolled back to an earlier state after a change caused trouble or needed to be undone. Teams use it for commits, features, configs, and entire deploys.
Revert Revert: To undo a previous revert, often because the original rollback was premature, incomplete, or later proved unnecessary. The phrase is a familiar sign that release history has become messy under pressure.
Revision: A specific, identifiable snapshot of a file or repository at a point in time, typically referenced by a unique identifier such as a commit hash in Git or a revision number in SVN. Each revision captures the exact state of all tracked content.
Semantic Commit: A commit message convention using a structured prefix (feat:, fix:, docs:, refactor:, test:, chore:) to describe the type of change. Enables automated changelog generation, semantic version bumping, and better git log readability. Also called Conventional Commits.
Source Control: A system that records changes to files over time so that specific versions can be recalled, compared, merged, and audited. Git is the dominant tool, enabling branching, distributed collaboration, and a full history of every change ever made to a codebase.
Squash: To combine commits into one, or more generally to eliminate a bug or problem decisively. The Git meaning is precise, while the bug-fixing meaning is looser developer slang.
Squash Merge: A merge strategy that combines all commits in a branch or pull request into a single commit before adding it to the target branch. Squash merges are often used to keep project history cleaner and easier to scan, especially for smaller PRs.
Stagit: A tiny static Git page generator from the suckless ecosystem that creates simple browsable repository websites without dynamic server-side application logic. It is often cited as an example of minimalist software philosophy applied to repository browsing.
Subcommand: A secondary command that follows the main program name in a CLI invocation, selecting a specific operation. For example, in `git commit`, `commit` is a subcommand of `git`, each with its own set of flags and arguments.
Submodule: A Git feature that embeds one repository inside another as a subdirectory, pinned to a specific commit. The parent repo stores a reference (not a copy) to the child repo, allowing you to version external dependencies or shared libraries alongside your code — though the resulting workflow is notoriou
Subtree: In data structures, any node and all its descendants within a tree. In Git, `git subtree` is an alternative to submodules that merges an external repository's history directly into a subdirectory of the host repo, allowing contributions without requiring collaborators to understand submodule workflo
Tag: A label or marker attached to an entity for identification or categorization — in HTML, an element like <div>; in Git, a named reference to a specific commit (often a release); in metadata systems, a keyword for classification.
Tidy: To clean up code formatting, remove dead code, fix linting violations, or reorganize imports without changing behavior — often done as a separate commit or PR to keep functional changes easy to review.
Trunk-Based Development: A branching strategy where developers commit directly to the main branch (trunk) or use very short-lived feature branches (< 1 day). Relies on feature flags, comprehensive CI, and small incremental changes. Reduces merge conflicts and enables continuous deployment.
Trunk-Based Development Culture: A team norm built around integrating changes into the main branch frequently and avoiding long-lived feature branches.
Unified Diff: A diff output format (produced by `diff -u` or `git diff`) that shows changes with surrounding context lines, using `---` and `+++` headers for file names, `@@` hunks for line ranges, `-` prefixes for removed lines, and `+` prefixes for added lines. It is the standard format for patches, pull reques
Upstream / Downstream: Upstream and Downstream in software development describe the relationship between original source repositories and their derivatives. Upstream refers to the original project or repository from which your copy was forked or from which you receive updates. Downstream refers to projects or forks that d
Version Control: The practice and tooling for tracking changes to files over time, enabling developers to revert to previous states, work on parallel branches, and merge contributions from multiple people. Git is the dominant implementation, though Mercurial and SVN persist in some organizations.
Version Control Culture: The norms around how a team uses version control, including commit hygiene, branching strategy, review discipline, merge practices, and historical readability. Healthy version control culture makes collaboration smoother and failure recovery easier.
Version Control System: Software that manages changes to a collection of files by recording each revision as a snapshot or set of diffs, supporting branching, merging, and history inspection. Modern systems like Git are distributed (every clone has full history), while older systems like SVN use a centralized server model.