Git Cheatsheet

How to use this Git cheatsheet

1. Browse by category, or search for a keyword.
2. Each command shows a short description of what it does.
3. Click any command to copy it to your clipboard.

Why keep a Git reference handy?

Git has dozens of commands and flags used only occasionally — a quick reference saves time compared to searching documentation every time you need to undo a commit or resolve a merge.

git reset --soft, --mixed, and --hard — what each one actually undoes

The three reset modes differ in exactly how much of your work they touch, and understanding the distinction is what makes reset safe to use rather than something to fear. --soft moves the branch pointer back to a specified commit but leaves both your staging area and working directory files completely untouched — your changes stay staged, ready to be committed again differently. --mixed (the default if no flag is given) also moves the branch pointer back, but additionally unstages those changes, leaving them present in your working directory as unstaged edits. --hard moves the branch pointer back and also overwrites your working directory files to match that earlier commit exactly, permanently discarding any uncommitted changes in the process — this is the only one of the three modes that can actually destroy work, which is exactly why it deserves real caution before running it, while --soft and --mixed are both fundamentally safe, non-destructive operations.

Merge versus rebase — the same integration goal, two different histories

Merge and rebase both integrate changes from one branch into another, but they produce meaningfully different-looking history, and understanding the tradeoff helps decide which fits a given situation. A merge creates a new commit with two parent commits, preserving the exact, literal history of both branches — including every intermediate commit exactly as they happened — which keeps an honest, complete record but can result in a busier, more tangled-looking commit graph over time. A rebase instead replays your branch's commits one by one on top of the target branch, producing a clean, linear history with no merge commits at all, at the cost of literally rewriting commit hashes, which means rebase should generally never be used on commits that have already been pushed and shared with others, since it invalidates history other people may have already built work on top of.

Why force-pushing is dangerous, and what --force-with-lease actually adds

A regular force push (git push --force) unconditionally overwrites whatever is on the remote branch with your own local history, completely regardless of whether someone else has pushed new commits to that same branch since you last fetched — which means it can silently and permanently destroy a teammate's work with absolutely no warning if their commits happen to be sitting on the remote at that moment. git push --force-with-lease is a meaningfully safer alternative: it first checks that the remote branch still matches exactly what your local copy last knew about it, and refuses to push at all if the remote has moved unexpectedly since your last fetch — correctly catching the specific case where someone else pushed in the meantime, rather than blindly overwriting their work without any check at all.

The staging area — the often-misunderstood step between editing and committing

Git's staging area (also called the index) is a genuinely distinctive design choice compared to many other version control systems, and it's often the single most confusing concept for people newer to Git specifically. Rather than committing your entire working directory's current state directly and all at once, Git requires an explicit intermediate "add" step, letting you deliberately choose exactly which specific changes go into the next commit — even hand-picking individual lines within a single file using git add -p, while leaving other changes in that same file uncommitted for later. This extra step exists specifically to enable building small, clean, focused, well-organized commits rather than one large, unfocused commit dumping every single change you happened to make in a work session, regardless of whether those changes were actually logically related to each other.

Limitations of this tool

This tool provides a searchable reference of the most commonly used Git commands for everyday development work — it doesn't cover every flag, every edge case, or Git's more advanced and rarely used commands (like the internal plumbing commands beneath Git's everyday porcelain interface). For the complete, fully authoritative command reference, Git's own built-in documentation (accessible via git help in your terminal) remains the definitive source — this cheatsheet is meant as a fast, convenient lookup for common day-to-day cases, not a full replacement for that official documentation.