godz.online
Back to tools

TLDR reference

Git commands

A searchable cheatsheet of everyday git tasks paired with the exact command. Type what you want to do, or filter by intent. Everything runs in your browser.

45 shown

How it works

A searchable cheatsheet for everyday git, organised around what you are trying to do rather than around the commands themselves. Type a goal in plain words - "undo last commit", "rename branch", "discard changes" - and the matching task jumps to the top with the exact command to run. The chips group tasks by intent: setup and config, staging and committing, branches, undoing and fixing, remotes, the stash, inspecting history, and tags.

Each card pairs the task with the precise command and a short note on what it does and when it is safe to use, so you can copy it with confidence instead of half-remembering the flags. It favours the modern commands where they exist - git switch and git restore over the older, overloaded git checkout - while still pointing out the classic equivalents. Everything is static and runs in your browser, so the lookup is instant and works offline.

Example. Searching "undo" surfaces several reset recipes side by side: git reset --soft HEAD~1 keeps your changes staged, git reset HEAD~1 unstages them, and git reset --hard HEAD~1 throws them away. Filtering by the Branches chip lists git switch -c, git branch -m, and git merge together so you can compare them at a glance.

FAQ

What is the difference between git reset, revert, and restore?

They undo different things. git restore discards changes in your working tree or unstages a file, touching no history. git reset moves the current branch to an earlier commit, optionally keeping or dropping the changes (--soft, mixed, --hard). git revert is the safe choice for commits you have already pushed: instead of rewriting history it adds a new commit that cancels out an old one, so collaborators are never left with a diverged branch.

How do I undo the very last commit?

It depends what you want to keep. To drop the commit but keep its changes staged, run git reset --soft HEAD~1. To keep the changes but unstage them, use git reset HEAD~1. To discard the commit and its changes entirely, git reset --hard HEAD~1 - but that is destructive, so only do it on commits you have not pushed. If you only need to fix the message or add a file, git commit --amend is cleaner.

When should I rebase instead of merge?

Use merge to combine finished branches: it preserves the true history and records a merge commit. Use rebase to tidy your own in-progress branch by replaying your commits on top of the latest main, giving a linear history that is easier to read. The golden rule is to never rebase commits that other people have already pulled, because it rewrites their hashes and forces everyone to reconcile a history that changed underneath them.

I think I lost a commit - can I get it back?

Usually yes. git reflog records every position HEAD has held, including commits left behind by a reset, a bad rebase, or a deleted branch. Find the commit hash in the reflog and run git reset --hard <hash> (or git switch -c rescue <hash>) to bring it back. Git keeps unreachable commits for weeks before garbage-collecting them, so a "lost" commit is almost always still recoverable.