A searchable Git cheat sheet covering setup, the daily commit loop, branching, remotes, history and recovery, with one-click copy for every command.
Forty-nine Git commands worth remembering. Filter across command names and descriptions, then copy the one you need. Grouped by setup, daily workflow, branching, remotes, history and undoing mistakes.
No command matches that filter.
Git has well over a hundred porcelain commands, but most engineers use the same twenty or thirty every day and reach for the rest a few times a year. A cheat sheet is not a substitute for understanding the model; it exists so that the commands you already understand stay one keystroke away instead of one browser tab and three Stack Overflow answers away.
The reference on this page is grouped the way work actually happens: setting up a repository, the commit loop you run dozens of times a day, branching, talking to a remote, reading history, and getting yourself out of trouble. Type into the filter box and the list narrows across both the command text and its description, so searching for "stash", "force" or "undo" surfaces the relevant rows immediately. Every row has a copy button, because retyping a command with a --force-with-lease in it is exactly how typos happen.
Almost every Git command makes sense once you hold three places in your head. The working tree is the files on disk as you see them in your editor. The index — also called the staging area — is the snapshot you are assembling for the next commit. The repository is the immutable chain of commits already recorded. git add moves content from the working tree into the index, git commit turns the index into a new commit, and git restore pushes content back the other way.
Branches are the second idea, and they are simpler than they look: a branch is just a movable pointer to one commit, and HEAD is a pointer to the branch you are on. Creating a branch costs nothing because it writes a single file containing a forty-character hash. That is why git switch -c is cheap enough to use for a five-minute experiment.
Merging and rebasing both combine work from two branches; they differ in what they record. A merge keeps both histories and adds a commit that joins them, which is honest but produces a braided graph. A rebase rewrites your commits so they appear to have been written on top of the other branch, which produces a clean straight line but changes commit hashes — which is exactly why you never rebase commits that other people have already pulled.
The single most useful thing to know about Git is that it very rarely loses committed work. As long as a change was committed at some point, git reflog will show you the hash, and git switch -c rescue <hash> will bring it back. That safety net covers botched rebases, accidental reset --hard after a commit, and branches deleted a little too eagerly.
The dangerous operations are the ones that touch uncommitted work: git reset --hard, git checkout -- on a modified file, and git clean -fd. None of those changes were ever recorded, so there is nothing for the reflog to point at. The habit worth building is to commit early and often on a scratch branch, or to git stash push before any experiment. A commit you later squash away costs nothing; an afternoon of uncommitted work does not come back.
On shared branches, prefer git revert over history rewriting. It records a new commit that reverses the old one, so everyone else's clone stays valid. Reserve --force-with-lease for your own feature branches, and note that it is meaningfully safer than plain --force: it refuses to run if the remote moved since you last fetched, which is precisely the case where a plain force push would silently destroy a colleague's commits.