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
-
Start a new repository
Setup & configgit init
Creates a new .git folder in the current directory so git begins tracking it.
-
Clone an existing repository
Setup & configgit clone <url>
Copies a remote repository, its full history, and sets up "origin" pointing back at it.
-
Set your name and email
Setup & configgit config --global user.name "Your Name" git config --global user.email "you@example.com"
These stamp every commit you make. --global applies to all repos; drop it to set per-repo.
-
Set the default branch name
Setup & configgit config --global init.defaultBranch main
New repositories created with git init will start on "main" instead of "master".
-
Add a useful alias
Setup & configgit config --global alias.lg "log --oneline --graph --all"
Now "git lg" prints a compact, graphed history. Aliases save typing on commands you repeat.
-
Stage all changes
Stage & commitgit add -A
Stages new, modified, and deleted files. Use "git add <file>" to stage a single one.
-
Commit staged changes
Stage & commitgit commit -m "Message"
Records the staged snapshot with a message. Keep the subject short and in the imperative.
-
Stage and commit tracked files in one step
Stage & commitgit commit -am "Message"
Skips "git add" for files git already tracks. New (untracked) files still need an add first.
-
Add more changes to the last commit
Stage & commitgit commit --amend --no-edit
Folds the staged changes into the previous commit and keeps its message. Do not amend pushed commits.
-
Change the last commit message
Stage & commitgit commit --amend -m "New message"
Rewrites just the message of the most recent commit. Only safe before you have pushed it.
-
Stage parts of a file interactively
Stage & commitgit add -p
Walks through each change hunk so you can commit some edits and leave others for later.
-
List branches
Branchesgit branch
Shows local branches; the current one is marked with *. Add -a to include remote branches.
-
Create and switch to a new branch
Branchesgit switch -c <branch>
Modern equivalent of "git checkout -b". Branches off the current commit.
-
Switch to an existing branch
Branchesgit switch <branch>
Moves your working tree to that branch. "git checkout <branch>" does the same on older git.
-
Rename the current branch
Branchesgit branch -m <new-name>
Renames the branch you are on. Add the old name first to rename a different branch.
-
Delete a branch
Branchesgit branch -d <branch>
Deletes a merged branch. Use -D (capital) to force-delete one with unmerged work.
-
Merge another branch into this one
Branchesgit merge <branch>
Combines that branch into your current branch, creating a merge commit if histories diverged.
-
Replay your commits on top of another branch
Branchesgit rebase <branch>
Moves your commits onto the tip of <branch> for a linear history. Avoid rebasing shared branches.
-
Undo the last commit but keep the changes
Undo & fixgit reset --soft HEAD~1
Removes the commit but leaves its changes staged, ready to recommit.
-
Undo the last commit and unstage the changes
Undo & fixgit reset HEAD~1
Drops the commit and unstages its changes, but keeps them in your working tree.
-
Throw away the last commit entirely
Undo & fixgit reset --hard HEAD~1
Deletes the commit and its changes. Destructive - the work is gone unless it is in the reflog.
-
Discard changes to a file
Undo & fixgit restore <file>
Resets the file to the last committed version. "git checkout -- <file>" did this on older git.
-
Unstage a file
Undo & fixgit restore --staged <file>
Removes the file from the staging area but keeps your edits. Same as "git reset <file>".
-
Revert a commit safely
Undo & fixgit revert <commit>
Creates a new commit that undoes <commit>. The safe way to undo work that is already pushed.
-
Recover a lost commit or branch
Undo & fixgit reflog
Lists where HEAD has been so you can find and reset back to a commit you thought was gone.
-
Show configured remotes
Remote & syncgit remote -v
Lists the remote names and their fetch/push URLs. "origin" is the usual default.
-
Add a remote
Remote & syncgit remote add origin <url>
Links a remote repository under the name "origin" so you can push and pull.
-
Push the current branch
Remote & syncgit push
Sends your commits to the tracked remote branch. First push of a new branch needs -u below.
-
Push a new branch and track it
Remote & syncgit push -u origin <branch>
Publishes the branch and sets it as upstream so later "git push" / "git pull" need no arguments.
-
Fetch remote changes without merging
Remote & syncgit fetch
Downloads new commits and updates remote-tracking branches, leaving your working branch untouched.
-
Pull remote changes
Remote & syncgit pull
Fetches and then merges (or rebases) the remote branch into your current branch.
-
Pull with rebase for a linear history
Remote & syncgit pull --rebase
Replays your local commits on top of the fetched ones instead of making a merge commit.
-
Stash your uncommitted changes
Stashgit stash
Saves tracked modifications away and gives you a clean working tree to switch tasks.
-
Stash including untracked files
Stashgit stash -u
Like git stash but also tucks away new files git is not yet tracking.
-
Reapply the latest stash
Stashgit stash pop
Restores the most recent stash and removes it from the stash list. Use "apply" to keep it.
-
List your stashes
Stashgit stash list
Shows every saved stash with its index, so you can pop or drop a specific one.
-
See what has changed
Inspect & historygit status
Shows staged, unstaged, and untracked files - your first stop before committing.
-
Show unstaged changes
Inspect & historygit diff
Prints the line-by-line difference between your working tree and the staging area.
-
Show staged changes
Inspect & historygit diff --staged
Shows what is about to be committed, comparing the staging area with the last commit.
-
View a compact commit history
Inspect & historygit log --oneline --graph
One line per commit with a branch graph - a readable overview of how history fits together.
-
See who changed each line
Inspect & historygit blame <file>
Annotates every line with the commit, author, and date that last touched it.
-
Find which commit introduced a bug
Inspect & historygit bisect start
Begins a binary search through history; mark commits good/bad to home in on the breaking one.
-
Create an annotated tag
Tagsgit tag -a v1.0.0 -m "Release 1.0.0"
Annotated tags store a message, tagger, and date - the right kind for releases.
-
List tags
Tagsgit tag
Shows all tags. Add -l "v1.*" to filter by a pattern.
-
Push tags to the remote
Tagsgit push --tags
Tags are not pushed by default; this sends them all so a release tag appears on the remote.
No commands match your search.
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.