Git Cheat Sheet

65+ Git commands with descriptions, flags, and examples. Search, filter by topic, click to copy. Includes workflow diagrams.

65 commands — Click any row to copy. Use Search to filter.

How to Use This Git Reference

  1. Quick Ref — all 65+ commands in topic groups, scrollable. Click any row to copy the command.
  2. By Topic — click a topic chip (Setup, Commits, Branches, etc.) to see only that group.
  3. Search — type any keyword (merge, stash, reset) to find relevant commands instantly.
  4. Workflow — view text-based diagrams for Feature Branch, Gitflow, and Trunk-Based Development workflows.

Essential Git Concepts

Git tracks three areas: the working directory (files on disk), the staging area / index (files marked for the next commit), and the repository (committed history). The workflow is always: edit files → stage changes with git add → commit with git commit. Understanding these three areas explains why most Git confusion happens — people mix up what is staged vs. committed vs. pushed.

Branching Strategy

Git branches are lightweight pointers to commits, making them fast to create and cheap to discard. The most important branching strategies are: Feature Branch (create a branch per feature, merge back to main when done — simplest and most widely used), Gitflow (separate develop and main branches with release, hotfix, and feature branch types — good for versioned releases), and Trunk-Based Development (commit directly to main with short-lived branches and feature flags — preferred by CI/CD-heavy teams like Google and Meta). The Workflow tab has diagrams for all three.

Remote Repositories

A remote is a version of your repository hosted on a server (GitHub, GitLab, Bitbucket, Azure DevOps). The default remote name is origin. Key remote commands: git remote add origin URL links your local repo to a remote; git push -u origin main pushes your code and sets the tracking branch; git fetch downloads remote changes without merging; git pull fetches and merges in one step. For team workflows, always git pull --rebase before pushing to avoid unnecessary merge commits.

Undoing Changes Safely

Git provides multiple ways to undo changes at different stages. For uncommitted working directory changes: git restore <file> (or git checkout -- <file> in older versions). For staged but uncommitted changes: git restore --staged <file>. For committed but unpushed changes: git reset HEAD~1 (keeps changes in working directory) or git reset --hard HEAD~1 (discards changes entirely). For changes already pushed to a shared branch: always use git revert <hash> — it creates a new undo commit without rewriting history, which is safe for everyone else on the team. Pair this reference with our Diff Checker when reviewing changes before committing.

Frequently Asked Questions

Git is a distributed version control system created by Linus Torvalds in 2005. It tracks file changes over time, enables team collaboration, and stores a complete history of every change ever made to a project. Every developer has a full local copy of the repository.
Merge creates a merge commit that preserves full branch history. Rebase rewrites history by replaying commits on top of the target, creating a linear history. Use merge for public branches; use rebase locally before opening a pull request.
git reset moves the branch pointer backward, removing commits from history. Only use on local unpushed commits. git revert creates a new commit that undoes a previous commit without rewriting history — safe to use on shared branches.
git stash temporarily saves uncommitted changes so you can switch branches. Changes go to a stack and can be reapplied later with git stash pop. Useful when you need to quickly fix a bug while in the middle of unfinished work.
git fetch downloads remote changes and updates remote-tracking branches but does not integrate them into your working branch. git pull = git fetch + git merge. Use fetch to review first; use pull when ready to integrate immediately.