Nobody opens a git cheatsheet to learn git. They open it because something went wrong two minutes ago and they need the exact incantation before the deploy window closes. So this one is grouped by symptom, not by alphabet, and it uses the modern commands rather than the overloaded ones.
Every reference sheet on the internet lists git checkout for four unrelated jobs, because that was true in 2010. Git split those jobs into git switch and git restore years ago, and the split exists precisely because checkout was the source of most accidental data loss. This sheet uses the newer commands where they apply and says so where the old one is still the only option.
Table of contents
- I want to undo something
- I need to move between branches
- I have local changes and I need them out of the way
- I need to sync with the remote
- I need to find out what happened
- I need to clean up before a review
- I have done something bad and I want it back
- The configuration worth setting once
- The commands that matter when a deploy is watching
- How this fits the rest of the stack
- FAQ
I want to undo something
The most common reason anyone reaches for a cheatsheet. Start here and read the whole line before running anything, because two of these discard work permanently.
# Discard changes to one file in the working tree (UNRECOVERABLE)
git restore path/to/file
# Unstage a file, keep the edits
git restore --staged path/to/file
# Undo the last commit, keep the changes staged
git reset --soft HEAD~1
# Undo the last commit, keep the changes unstaged
git reset --mixed HEAD~1
# Undo the last commit and throw the changes away (UNRECOVERABLE)
git reset --hard HEAD~1
# Undo a commit that is already pushed, by adding a new commit
git revert <commit>The rule that keeps people out of trouble: reset rewrites history and is for commits nobody else has pulled. revert adds a new commit that reverses an old one and is the correct tool for anything already on a shared branch.
If you have already run something destructive, do not close the terminal. Go to the recovery section at the bottom.
I need to move between branches
# Switch to an existing branch
git switch main
# Create a branch and switch to it
git switch -c feature/new-thing
# Create a branch from a specific commit or tag
git switch -c hotfix v1.4.2
# Go back to the branch you were just on
git switch -
# List local branches, with the current one marked
git branch
# List every branch including remotes
git branch -a
# Delete a merged local branch
git branch -d old-feature
# Delete an unmerged local branch anyway
git branch -D old-feature
# Delete the remote branch too
git push origin --delete old-featuregit switch only switches branches. git checkout also restores files, which is how people have historically wiped a working tree while trying to change branch. Use switch and the mistake becomes impossible.
I have local changes and I need them out of the way
# Stash tracked changes
git stash
# Stash with a label you will recognise tomorrow
git stash push -m "half-done auth refactor"
# Include untracked files (the usual reason a stash looks empty)
git stash -u
# List what is stashed
git stash list
# Reapply the most recent stash and keep it in the list
git stash apply
# Reapply and remove it from the list
git stash pop
# Look at a stash before applying it
git stash show -p stash@{1}The untracked-files flag is the one people miss. A plain git stash leaves new files sitting in the working tree, so you switch branches and find them still there, which is confusing in a way that costs ten minutes.
I need to sync with the remote
# Download remote state without touching your branch
git fetch origin
# Fetch and merge the tracked branch
git pull
# Fetch and rebase instead of merging (linear history)
git pull --rebase
# Push a new local branch and set up tracking
git push -u origin feature/new-thing
# Push after a rebase, safely
git push --force-with-lease
# See what would be pushed
git log origin/main..HEAD --oneline--force-with-lease instead of --force is the single most valuable habit on this page. Plain force overwrites the remote unconditionally, including a colleague’s commit pushed while you were rebasing. The lease version refuses if the remote moved since your last fetch. Same keystrokes, one fewer incident.
I need to find out what happened
# Compact history with the branch graph
git log --oneline --graph --decorate --all
# What changed in a file, across renames
git log --follow -p path/to/file
# Who last touched each line
git blame path/to/file
# Search commit messages
git log --grep="timeout"
# Search for a commit that added or removed a string
git log -S "DATABASE_URL"
# What is different between two branches
git diff main..feature/new-thing
# Find the commit that introduced a bug
git bisect start
git bisect bad
git bisect good v1.3.0git log -S is underused and disproportionately effective. When a config value or function name disappeared and nobody remembers when, it finds the exact commit in one command.
I need to clean up before a review
# Amend the last commit (message or content)
git commit --amend
# Amend without opening an editor
git commit --amend --no-edit
# Squash and reword the last four commits
git rebase -i HEAD~4
# Bring your branch up to date on top of main
git switch feature/new-thing
git fetch origin
git rebase origin/main
# Apply one commit from another branch
git cherry-pick <commit>Rebase rewrites commit hashes. That is fine on a branch only you are working on and disruptive on a shared one. The convention worth keeping: rebase your own feature branch as much as you like, merge into shared branches.
I have done something bad and I want it back
Almost everything in git is recoverable for around ninety days, because the reflog records every position HEAD has held, including the ones you rewrote away.
# Every recent position of HEAD, including resets and rebases
git reflog
# Go back to a specific one
git reset --hard HEAD@{4}
# Or just recover the lost commit onto a new branch
git switch -c recovered HEAD@{4}
# Find commits that no branch points to any more
git fsck --lost-foundThe exception, and it is an important one: git restore on an uncommitted file has nothing to recover from. The change was never in the object database. Commit early on anything you would be annoyed to lose, even to a scratch branch.
The configuration worth setting once
git config --global user.name "Your Name"
git config --global user.email [email protected]
# Sensible default for pull
git config --global pull.rebase true
# Push only the current branch
git config --global push.default current
# Remember conflict resolutions and reapply them
git config --global rerere.enabled true
# See everything currently set, and where it came from
git config --list --show-originrerere is the quiet win. If you rebase a long-lived branch repeatedly and resolve the same conflict every time, it records the resolution and applies it automatically on the next occurrence.
The commands that matter when a deploy is watching
If a push triggers a build, a handful of these change from convenience to consequence.
git log origin/main..HEAD --onelinebefore pushing, so you know exactly what is about to deploy.git push --force-with-leaserather than--force, because a shared branch plus a plain force push is how a deploy ends up shipping a colleague’s reverted work.git revertrather thangit reseton anything already deployed, so the rollback is itself a commit with a history.git tag -a v1.4.2 -m "release"on the commit you deployed, so the next incident starts with a known-good reference point.
That last one pays for itself the first time something breaks. A platform that deploys from the repository and keeps a rollback to the previous deploy gives you the same guarantee at the infrastructure layer, which means the tag and the running version agree with each other.
How this fits the rest of the stack
A cheatsheet is only useful if the thing on the other end of the push is predictable. Deploying from the repository, with a build log per commit and a rollback to the previous deploy, is what makes git revert a thirty-second fix rather than an outage. If you are pricing that setup, the RunxBuild hosting calculator lays out the service, the database, and the bandwidth as separate numbers so the deploy path has a cost you can see.
Useful related references:
- Git Pull All Branches: Why the Command You Want Does Not Exist
- The scp Command: Syntax, Traps, and When to Use Something Else
- Linux Shutdown Command: shutdown, reboot, halt, and systemd
- Services on RunxBuild
FAQ
What is the difference between git switch and git checkout?
git switch only changes branches. git checkout does that and also restores files from a commit, which is why it has historically caused accidental data loss. Use switch for branches and restore for files; checkout still works but does too many things.
How do I undo the last commit without losing my work?
git reset —soft HEAD1 removes the commit and leaves the changes staged. git reset —mixed HEAD1 leaves them unstaged. Only —hard discards them, and only use it on commits nobody else has pulled.
What is the difference between git reset and git revert?
reset rewrites history by moving the branch pointer. revert creates a new commit that undoes an old one. Use reset on local commits, revert on anything already pushed to a shared branch.
Is git push —force-with-lease safer than —force?
Yes. It refuses the push if the remote branch has moved since your last fetch, so it cannot silently overwrite a commit someone else pushed. There is no reason to prefer plain —force.
Can I recover a commit after git reset —hard?
Usually yes. git reflog lists every recent position of HEAD, including the one you reset away from, and you can reset or branch back to it. This does not work for uncommitted changes discarded with git restore, which were never stored.