Git Cheat Sheet
Complete Git command reference, organized by category for quick lookup
Basic Commands(13)
Create a new Git repository in current directory
Clone a remote repository to local
Shallow clone, fetch only the latest commit
Add file to staging area
Add all changes to staging area
Commit staged changes
Modify the last commit
Show repository current status
Show unstaged changes
Show staged changes
View all configuration
Set global username
Set global email
Branch Management(14)
List all local branches
List all branches (including remote)
Create new branch
Delete branch
Rename branch
Switch branch
Create and switch to new branch
Switch branch (Git 2.23+)
Create and switch to new branch (Git 2.23+)
Merge specified branch to current
Merge branch with merge commit
Rebase current branch onto specified
Continue rebase after resolving conflicts
Cherry-pick specific commit to current branch
Remote Operations(10)
View remote repository info
Add remote repository
Fetch latest content from remote
Fetch updates from all remotes
Pull and merge remote branch
Pull and rebase
Push to remote repository
Force push (use with caution)
Push and set upstream branch
Delete remote branch
Undo Changes(8)
Unstage file
Undo last commit, keep changes
Undo commit and staging, keep working directory
Undo commit and discard all changes
Undo specified commit (creates new commit)
Restore working directory file (Git 2.23+)
Unstage file (Git 2.23+)
Remove untracked files and directories
Tag Management(6)
List all tags
Create lightweight tag
Create annotated tag
Delete local tag
Push tag to remote
Push all tags to remote
History Viewing(7)
View commit history
Show compact commit history
Show all branch history graphically
Show commit details
Show line-by-line modification history
Show all operation history
Start binary search for problem commit
Stash(7)
Stash current changes
Stash changes with message
List all stashes
Apply and drop latest stash
Apply latest stash without dropping
Drop latest stash
Clear all stashes
What is Git?
A Git cheat sheet is a quick reference for common version-control commands, grouped by the task you are trying to perform. Git itself is a distributed version control system: every clone contains project history, branches are lightweight pointers, and commits form a record of how a codebase changed over time. The cheat sheet helps when you remember the workflow but not the exact syntax, such as checking staged changes, creating a branch, undoing a commit, stashing work, tagging a release, or synchronizing with a remote. It is a reference, not a substitute for understanding repository state. Destructive commands like reset --hard, clean -fd, rebase, and force push should be copied only after checking uncommitted work, current branch, and remote impact.
Usage Guide
Quick Reference
- Click any command card to copy the command
- Use search box to quickly find specific commands
- Click category tags to filter by type
- Hover over commands to see detailed descriptions
Features
Advanced Tips
- Use git restore --staged to unstage files
- Use git commit --amend to modify last commit
- Use git stash to temporarily save work progress
- Use git revert to undo pushed commits
Use Cases
Technical Principle
Local changes flow through three areas: the working directory, the index (also called the staging area, stored in .git/index), and the object database. git add records blob hashes into the index, git commit freezes the index into a new tree plus commit object, and git checkout/switch updates the index and working tree to a target commit. Merges fall into two categories: fast-forward simply advances the branch pointer when the target is a direct descendant, while three-way merges (recursive or ort strategy) compute a common ancestor and build a merge commit with two parents. git rebase rewrites history by replaying commits one-by-one onto a new base, producing new SHAs.
Remote synchronization runs over the HTTPS smart protocol, SSH, or the deprecated git:// protocol, exchanging pack files generated by delta compression. After a fetch, Git stores the snapshot under refs/remotes/origin/* and the reflog under .git/logs/ keeps a 90-day undo trail by default (gc.reflogExpire) so even reset --hard or a botched rebase can be recovered before garbage collection prunes unreachable objects.
- Object model: blob, tree, commit, tag — content-addressed by SHA-1 (or SHA-256 since 2.29), stored loose under .git/objects/xx/ or packed in .git/objects/pack/*.pack
- Index/staging: .git/index is a binary file mapping path → blob hash + stat info; git add updates it, git commit freezes it into a tree
- Refs and HEAD: refs/heads/<branch>, refs/remotes/<remote>/<branch>, refs/tags/<tag> are plain files containing a SHA; HEAD is a symbolic ref to the current branch
- Merge strategies: fast-forward when target is a descendant, otherwise three-way recursive/ort merge using the merge base; --no-ff forces a merge commit
- Rebase rewrites: git rebase replays commits onto a new base producing new SHAs, breaking shared history if pushed — hence --force-with-lease is preferred over --force
- Reflog recovery: .git/logs/HEAD and per-ref logs retain ref movements for 90 days (gc.reflogExpire); git reflog plus git reset restores after destructive operations
- Transport: smart HTTPS, SSH, or git:// negotiate pack files via the upload-pack/receive-pack protocol; shallow clones use --depth to limit history
Examples
Create and switch to new branch
git checkout -b feature/login # Create and switch to new branchUndo working directory changes
git restore filename # Restore file to last committed stateView commit history
git log --oneline --graph --all # Graphically show all branch historyFAQ
How do I undo my most recent commit?
git reset --soft HEAD~1 keeps your changes staged so you can recommit; git reset --mixed HEAD~1 keeps them in the working tree but unstaged; git reset --hard HEAD~1 throws them away. If the commit is already pushed, use git revert HEAD instead, which creates a new commit that undoes the change without rewriting history.
What is the difference between git pull and git fetch?
git fetch only downloads commits from the remote into your local refs - it never touches your working branch. git pull is equivalent to git fetch followed by git merge (or git rebase if --rebase is set). Use fetch when you want to inspect upstream changes before integrating them.
How do I discard local changes to a file?
git restore <file> drops uncommitted edits in the working tree; git restore --staged <file> unstages a file without losing its content; git checkout HEAD -- <file> restores the version from the latest commit. For untracked files use git clean -f or -fd to remove directories too.
When should I rebase vs merge?
Rebase when you want a linear history on a private feature branch before merging it back. Merge when integrating a shared branch where preserving the actual development history matters. Never rebase commits that have been pushed to a shared branch unless everyone agrees - it rewrites SHAs and breaks other people's clones.
How do I see what's about to be pushed?
git log @{u}.. shows commits on your branch that are not on the upstream. git diff @{u} shows the combined diff. git status compared to origin (after a fetch) shows ahead/behind counts.
How do I recover a deleted branch or lost commit?
git reflog lists every position HEAD has been at; find the SHA of the commit you lost and run git checkout <sha> or git branch <name> <sha>. Reflog entries last about 90 days by default before garbage collection, so do this soon after the mistake.
What's the safest way to amend a commit?
git commit --amend lets you edit the most recent commit's message or add forgotten files. It rewrites the SHA, so only do it on local commits that have not been pushed. If you must amend a pushed commit, push with --force-with-lease (not --force) to avoid clobbering teammates' updates.