Git has hundreds of commands and thousands of flags. Nobody knows all of them. The developers who look like Git experts are actually just very comfortable with about 20 commands that cover 95 percent of everyday work.
This cheat sheet focuses on those 20 commands, organized by the situations where you actually need them. It is not an exhaustive reference (the official docs handle that). It is the set of commands you will reach for during normal development work, plus the rescue commands for when things go sideways.
Bookmark this page. You will come back to it.
Starting and Cloning
Initialize a new repository:
`bash
git init
`
Creates a .git directory in your current folder. This is how you turn any directory into a Git repository.
Clone an existing repository:
`bash
git clone https://github.com/user/repo.git
git clone git@github.com:user/repo.git # SSH
`
Downloads the entire repository history and sets up a remote called origin pointing to the source.
Clone only the latest commit (shallow clone, faster for large repos):
`bash
git clone --depth 1 https://github.com/user/repo.git
`
Check the current state of your working directory:
`bash
git status
`
Shows which files are modified, staged, untracked, or in conflict. This is the command you will run most often. When in doubt, run git status first.
Staging and Committing
Stage specific files:
`bash
git add file.txt
git add src/components/Button.tsx
git add *.css # all CSS files
`
Stage all changes (use with caution):
`bash
git add .
`
Stages everything in the current directory and subdirectories. Be careful not to stage files you do not want to commit (log files, environment files, build artifacts). Check git status before committing.
Commit staged changes:
`bash
git commit -m "Add user authentication flow"
`
The message should describe what changed and why. Good: "Fix pagination bug on search results page." Bad: "Update code" or "fixes."
Amend the last commit (before pushing):
`bash
git commit --amend -m "Better commit message"
`
Rewrites the most recent commit. Never amend commits that have already been pushed to a shared branch.
See what changed before committing:
`bash
git diff # unstaged changes
git diff --staged # staged changes
`
The Diff Checker provides a visual side-by-side view if you prefer that over terminal output. Paste the old and new versions of a file and see the differences highlighted.
**Stage specific files**: ```bash git add file.txt git add src/components/Button.tsx git add *.css # all CSS files ``` **Stage all changes** (use with caution): ```bash git add .
Branching and Merging
Create and switch to a new branch:
`bash
git checkout -b feature/new-login
# or the newer syntax:
git switch -c feature/new-login
`
List all branches:
`bash
git branch # local branches
git branch -a # local + remote branches
`
Switch between branches:
`bash
git checkout main
# or:
git switch main
`
Merge a branch into your current branch:
`bash
git merge feature/new-login
`
If there are no conflicting changes, this completes automatically. If there are conflicts, Git marks the conflicting files and you need to resolve them manually.
Delete a branch after merging:
`bash
git branch -d feature/new-login # safe delete (only if merged)
git branch -D feature/new-login # force delete (even if not merged)
`
Rebase instead of merge (cleaner history):
`bash
git checkout feature/new-login
git rebase main
`
Rebasing replays your branch's commits on top of the target branch. It produces a linear history without merge commits. Use rebase for feature branches. Use merge for shared branches.
The golden rule: never rebase commits that other people are working on. Rebase rewrites history, and that causes problems when multiple people share the same branch.
Working With Remotes
Push your branch to the remote:
`bash
git push origin feature/new-login
# Set upstream so future pushes are simpler:
git push -u origin feature/new-login
# After setting upstream:
git push
`
Pull the latest changes from the remote:
`bash
git pull # fetch + merge
git pull --rebase # fetch + rebase (cleaner)
`
git pull --rebase is generally preferred because it avoids the unnecessary merge commits that git pull creates when your local branch has diverged from the remote.
Fetch without merging (see what changed without applying):
`bash
git fetch origin
git log origin/main..main # see commits on remote that you don't have
`
View remote URLs:
`bash
git remote -v
`
Add a new remote (for example, a fork):
`bash
git remote add upstream https://github.com/original/repo.git
`
Sync a fork with the upstream repository:
`bash
git fetch upstream
git checkout main
git merge upstream/main
git push origin main
`
Stashing: Saving Work Without Committing
Stash your current changes:
`bash
git stash
`
Removes all uncommitted changes from your working directory and saves them. Your working directory goes back to the last commit. Use this when you need to switch branches but are not ready to commit.
Stash with a descriptive message:
`bash
git stash push -m "WIP: login form validation"
`
List your stashes:
`bash
git stash list
`
Shows all saved stashes with their index numbers and messages.
Apply the most recent stash:
`bash
git stash pop # apply and remove from stash list
git stash apply # apply but keep in stash list
`
Apply a specific stash:
`bash
git stash apply stash@{2}
`
Drop a stash you no longer need:
`bash
git stash drop stash@{0}
`
Stashing is underused by many developers. It is the fastest way to context-switch between tasks without creating throwaway commits or losing work. Get comfortable with it and you will use it multiple times per day.
Recovering From Mistakes
Undo the last commit but keep the changes:
`bash
git reset --soft HEAD~1
`
The commit disappears, but all changes remain staged. Useful when you committed too early or with the wrong message.
Undo the last commit and unstage the changes:
`bash
git reset HEAD~1
`
The commit disappears and changes go back to the working directory (unstaged).
Discard all local changes (nuclear option):
`bash
git checkout .
# or:
git restore .
`
This throws away all uncommitted changes in all files. There is no undo. Make sure you really want this.
Revert a commit that has already been pushed:
`bash
git revert abc1234
`
Creates a new commit that undoes the changes from the specified commit. Unlike reset, revert is safe for shared branches because it does not rewrite history.
Find a lost commit with reflog:
`bash
git reflog
`
Shows a log of every HEAD change, including commits that are no longer on any branch. If you accidentally deleted a branch or reset too far, the commit is probably still in the reflog for 30 days.
You can preview any changes you are about to make using the Diff Checker before committing. Paste your current code and the intended version side by side to verify the changes are what you expect. Document your Git workflow decisions in Markdown files and preview them with the Markdown Preview tool.
**Undo the last commit but keep the changes**: ```bash git reset --soft HEAD~1 ``` The commit disappears, but all changes remain staged.
FAQ
What is the difference between git merge and git rebase?
Merge creates a new "merge commit" that combines the histories of both branches. Rebase replays your commits on top of the target branch, producing a linear history. Merge preserves the exact history of how branches evolved. Rebase produces a cleaner log but rewrites commit hashes. Use rebase for your own feature branches, merge for shared branches.
How do I resolve merge conflicts?
When Git cannot automatically merge, it marks the conflicting sections in the affected files with <<<<<<<, =======, and >>>>>>> markers. Open each file, choose which version to keep (or combine them), remove the markers, stage the file with git add, and complete the merge with git commit.
Should I use git pull or git fetch?
Use git fetch when you want to see what changed on the remote without modifying your local branch. Use git pull when you want to immediately incorporate remote changes. git pull --rebase is the cleanest option for most workflows because it avoids unnecessary merge commits.
How do I undo a git push?
You cannot truly undo a push, but you can revert its effects. Use git revert to create a new commit that undoes the pushed changes. Then push the revert commit. Never use git push --force on shared branches unless you have communicated with your team, because it overwrites history for everyone.
Markdown Table Generator: Build Clean Tables Without the Pain
Markdown tables are simple until the pipes and dashes stop lining up. Learn the syntax, alignment tricks, and a free tool that formats tables for you.
CSV to JSON: Convert Spreadsheet Data for APIs and Code
Turn a CSV export into clean JSON for APIs, imports, and scripts. Learn how the conversion works, common pitfalls with types and quotes, and a free tool.
JSON Guide: Format, Validate, and Convert JSON Files
JSON guide for developers: syntax rules, common parse errors, formatting and schema validation, plus how to convert between JSON and CSV files.