Git Commands Cheat Sheet: The Commands You Actually Use, With Examples
A practical Git reference grouped by what you are trying to do, from your first commit to undoing a mistake. Keep it open while you work, and use the undo guide before you reach for anything risky.
- A change moves through three areas: working directory, staging area and repository.
git statusis the safest command you have, so run it constantly.- Use
git revertto undo shared commits, and keepgit reset --hardfor local work you are sure about. git reflogcan usually rescue commits you thought were lost.
Nobody remembers every Git command, and you do not need to. This Git commands cheat sheet focuses on the small set that covers nearly all daily work, grouped by the job you are trying to do.
We tested the local commands in a throwaway demo repository using Git for Windows, and the output shown comes from that run, with line-ending warnings removed. Your commit hashes will differ. The remote commands need a server, so we did not run those. New to version control? Start with our Git tutorial for beginners.
How Git thinks: three areas
Most confusion disappears once you know where a change lives:
| Area | What it holds | Moved there by |
|---|---|---|
| Working directory | Your files as you edit them | Editing |
| Staging area (index) | Changes selected for the next commit | git add |
| Local repository | Your saved commit history | git commit |
| Remote repository | The shared copy, such as on GitHub | git push |
Setup and starting a project
| Command | What it does |
|---|---|
git config --global user.name "Asha" |
Sets your name on commits |
git config --global user.email "a@b.com" |
Sets your email on commits |
git config --global init.defaultBranch main |
Names new default branches main |
git init |
Creates a repository in the current folder |
git clone <url> |
Downloads an existing repository |
git config --list |
Shows your current settings |
Save your work
| Command | What it does |
|---|---|
git status |
Shows what has changed |
git add file.txt |
Stages one file |
git add . |
Stages all changes in this folder |
git add -p |
Stages selected parts of a file |
git diff |
Shows unstaged changes |
git diff --staged |
Shows what will be committed |
git commit -m "Message" |
Saves staged changes as a commit |
git commit -am "Message" |
Stages tracked files and commits them |
Here is how the short status view changes as a new file moves along:
$ echo "hello" > app.txt
$ git status --short
?? app.txt
$ git add app.txt
$ git status --short
A app.txt
$ git commit -m "Add app file"
?? means untracked, and A means added to staging. In the two-column format, the left column is the staging area and the right column is your working directory. Note that git commit -am skips brand new files, so you must add those explicitly first.
Branches
| Command | What it does |
|---|---|
git branch |
Lists local branches |
git branch -a |
Includes remote branches |
git switch feature/login |
Moves to a branch |
git switch -c feature/login |
Creates a branch and moves to it |
git merge feature/login |
Merges that branch into the current one |
git rebase main |
Replays your commits on top of main |
git branch -d feature/login |
Deletes a merged branch |
git branch -D feature/login |
Force deletes an unmerged branch |
Here is a small feature branch from start to finish:
$ git switch -c feature/login
$ echo "login" >> app.txt
$ git commit -am "Add login"
$ git switch main
$ git merge --no-edit feature/login
$ git log --oneline --graph
* d0450b6 Add login
* 676b684 Add app file
$ git branch -d feature/login
Deleted branch feature/login (was d0450b6).
The history is a straight line because main had not moved, so Git did a fast-forward merge. You will still see git checkout in older guides. It works, but the newer switch and restore commands split its many jobs into clearer ones. To choose between merging and rebasing, read Git merge vs rebase.
Working with remotes
| Command | What it does |
|---|---|
git remote -v |
Lists remotes and their URLs |
git remote add origin <url> |
Connects a remote |
git fetch |
Downloads changes without merging |
git pull |
Fetches, then integrates into your branch |
git push |
Uploads your commits |
git push -u origin feature/login |
Pushes a new branch and tracks it |
git push origin --delete feature/login |
Deletes a remote branch |
git push --force-with-lease |
Force pushes, but only if nobody else has pushed |
fetch is always safe, because it never changes your files. If you need to overwrite a branch after a rebase, prefer --force-with-lease to plain --force, as it refuses to wipe out a colleague’s new commits.
Stash: set work aside
Stash is useful when you need to switch tasks but are not ready to commit:
$ echo "wip" >> app.txt
$ git stash
$ git status --short
# clean, the change is put away
$ git stash pop
$ git status --short
M app.txt
| Command | What it does |
|---|---|
git stash |
Saves changes and cleans your working directory |
git stash -u |
Includes untracked files |
git stash list |
Shows saved stashes |
git stash pop |
Restores the latest stash and removes it |
git stash apply |
Restores it but keeps it saved |
View history
| Command | What it does |
|---|---|
git log --oneline |
Shows one line per commit |
git log --oneline --graph --all |
Draws all branches |
git log -p file.txt |
Shows a file’s changes over time |
git show <hash> |
Shows one commit in detail |
git blame file.txt |
Shows who last changed each line |
git reflog |
Shows everywhere HEAD has been |
git bisect |
Binary searches for the commit that added a bug |
Undo mistakes: “I want to…”
This is the part most people look up. Find your situation:
| Situation | Command |
|---|---|
| Discard unstaged edits in a file | git restore file.txt |
| Unstage a file but keep the edits | git restore --staged file.txt |
| Fix the last commit’s message or files | git commit --amend |
| Undo the last commit, keeping changes staged | git reset --soft HEAD~1 |
| Undo the last commit, keeping changes unstaged | git reset HEAD~1 |
| Undo a pushed commit safely | git revert <hash> |
| Throw away all local changes | git reset --hard |
| Remove untracked files | git clean -fd (preview with -n) |
| Recover a “lost” commit | git reflog, then git branch rescue <hash> |
Tip: Before anything risky, run git branch backup. It costs nothing and gives you a label to return to. git reset --hard and git clean can permanently destroy uncommitted work, which even reflog cannot recover.
Reset vs revert vs restore
These three names cause much confusion, but they do quite different things:
| Command | Acts on | Changes history? | Safe on shared branches? |
|---|---|---|---|
git restore |
Files | No | Yes, but it discards local edits |
git revert |
A commit, by adding its opposite | Adds to it | Yes |
git reset |
The branch pointer | Rewrites it | No |
In our demo, we committed a bad line and reverted it. The file went back to its earlier content, while the mistake stayed visible in the log as history:
$ echo "oops" >> app.txt
$ git commit -am "Bad change"
$ git revert --no-edit HEAD
$ cat app.txt
hello
login
Then git reset --soft HEAD~1 removed that last commit but kept its changes staged, which git status --short showed as M app.txt.
Tags
| Command | What it does |
|---|---|
git tag |
Lists tags |
git tag v1.0 |
Creates a lightweight tag |
git tag -a v1.0 -m "Release" |
Creates an annotated tag, best for releases |
git push origin v1.0 |
Pushes a tag (tags do not push by default) |
Tags often trigger release pipelines, as our GitHub Actions CI/CD guide explains.
A simple daily workflow
git switch main
git pull
git switch -c feature/search
# edit files
git status
git add -p
git commit -m "Add search by product name"
git push -u origin feature/search
# open a pull request, get a review, then merge
Write commit messages that explain the change in the imperative, like “Fix login redirect”. You will thank yourself when reading the log six months from now.
Common mistakes
- Committing secrets. Removing a file in a later commit does not remove it from history. Rotate the secret immediately, and use
.gitignore. - Rewriting shared history. Do not reset or rebase commits that others have already pulled.
- Using
git add .blindly. Checkgit statusfirst, so build files and logs stay out. - Using plain
--force. Prefer--force-with-lease. - Making huge commits. Small ones are easier to review, revert and bisect.
Final thoughts
Learn the three areas and a dozen commands, and Git stops being scary. Keep the undo table handy and remember that git status and git reflog are your safety net. To build confidence, create a throwaway repository, and deliberately break and repair it, since that is the cheapest place to make mistakes.
Frequently asked questions
What are the most used Git commands?
The everyday set is git status, add, commit, push, pull, switch, branch, merge and log. Those few commands cover most of a typical working day.
How do I undo my last commit in Git?
If it is local, use git reset –soft HEAD~1 to keep the changes staged. If you have already pushed it, use git revert so that history stays intact for others.
What is the difference between git fetch and git pull?
git fetch only downloads new data and leaves your files alone. git pull fetches and then merges or rebases those changes into your current branch.
What is the difference between git reset and git revert?
git reset moves the branch pointer and can rewrite history. git revert adds a new commit that undoes an earlier one, which makes it safe on shared branches.
Can I recover a deleted branch in Git?
Usually, yes. Find its last commit with git reflog, then recreate the branch with git branch name followed by the hash, provided Git has not yet cleaned it up.
Keep learning
Need help with testing, WordPress or SEO?
We help teams ship better software and grow their sites. Tell us what you are working on and we will suggest a clear next step.