← Dashboard

cheat sheets / tools

Git & Command-Line Cheat Sheets

The Git reference nobody outgrows, two tools that give you a cheat sheet for any command without leaving the terminal, and the model that makes Git's undo commands stop being guesswork.

updated aug 2026·4 references·a 7-minute read·free

Some tools you use constantly and never fully memorize. Git is the standard example: most developers touch it every day for years and still search for how to undo things. That is not a failure of memory. Git's commands make sense only once you understand what they operate on, and almost nobody is taught that part. This page lists the references worth keeping and then covers the model that makes them readable.

01 · VERSION CONTROL

Git

The one tool every developer uses and no one fully remembers. GitHub's printable card covers the everyday commands.

02 · THE GIT MODEL

Three places your work can be

Git tracks content in three areas, and every confusing command becomes clear once you can name which one it touches. There is the working directory, the files as they exist on disk. There is the staging area, a snapshot you are assembling for the next commit. And there is the repository, the committed history itself.

The undo commands map directly onto those areas. Discarding changes to a file in the working directory is a different operation from unstaging something you already added, which is different again from changing what a branch points at. This is the reason a single "undo" command does not exist: the question "undo what?" has three legitimate answers, and Git makes you pick.

Reset and revert are not alternatives

Reset moves a branch pointer, rewriting what history looks like from that branch's perspective. Revert creates a new commit that undoes an earlier one, leaving the original in place. On a branch nobody else has pulled, reset is convenient. On a shared branch, revert is the correct choice, because rewriting history other people have already based work on creates real problems for them.

TIPGit almost never loses a commit. It keeps a log of everywhere your branch tips have pointed, so a branch you reset away by mistake is usually still recoverable. Learning that this log exists, before you need it, converts the most stressful Git moments into a short lookup. Uncommitted work is the genuine exception, which is an argument for committing often.

03 · ANY COMMAND, INSTANTLY

Universal command references

A cheat sheet for whatever command you are stuck on, without opening a browser. These two solve the same problem in slightly different ways: tldr gives you the handful of examples people actually use, and cheat.sh aggregates more broadly and answers looser questions.

Neither replaces the manual page. Manual pages are exhaustive and precise, which is exactly what you want when you need to know whether a flag has a subtle behavior, and exactly what you do not want when you simply need to remember how to extract an archive. Using the example-first tools for recall and the manual for correctness is the sensible division.

04 · HABITS

What actually makes Git painless

Commit more often than feels necessary. Small commits are easier to review, easier to revert cleanly, and mean less unrecoverable work if something goes wrong, since uncommitted changes are the one thing Git genuinely cannot get back for you.

Write messages that explain why rather than restating what. The diff already shows what changed. Six months later the useful information is the constraint or decision that made the change necessary, and that exists nowhere else once the author has forgotten it.

Check what you are about to commit rather than staging everything reflexively. Reviewing the staged diff before committing catches debugging statements, stray credentials, and unrelated changes that would otherwise muddy the history. It takes seconds and prevents the class of mistake that is embarrassing to fix in public.

WORTH KNOWINGworking dir / staging / reporeset vs revertthe reflogreview before commitwhy, not what

05 · FAQ

Frequently asked questions

Are these developer tool cheat sheets free?

Yes. GitHub publishes its Git reference free, and tldr, cheat.sh, and Devhints are free community projects with no account required.

What is the difference between git reset and git revert?

Reset moves a branch pointer and rewrites what the history looks like, while revert adds a new commit that undoes an earlier one and leaves the original in place. Reset is fine on branches nobody else has pulled, and revert is the correct choice on shared branches.

Can I recover work after a bad git reset?

Usually yes, if it was committed. Git keeps a log of everywhere your branch tips have pointed, so a discarded commit can generally be found and restored from there. Uncommitted changes are the real exception, which is a good argument for committing frequently.

Should I use tldr or the man page?

Use tldr when you need to remember how to do something common, since it gives you the few examples people actually use. Use the manual page when you need precision about a flag's behavior, because it is exhaustive in a way the example-first tools deliberately are not.

What makes a good commit message?

One that explains why the change was necessary rather than restating what changed, since the diff already shows the what. The reasoning behind a change is the part that exists nowhere else once the author has forgotten it.

More cheat sheets

Quick references by area.