Git Command Reference for Developers
Git has an enormous command surface, but day-to-day work uses a small, consistent subset. This reference covers those commands grouped by task, with special attention to the operations that are easy to get subtly wrong — the difference between reset and revert, or between merge and rebase, is exactly where developers get into trouble.
Key Takeaways
- git status and git log are your two most important "look before you act" commands — use them before anything destructive
- git reset rewrites history (dangerous on shared branches); git revert creates a new commit that undoes changes (safe on shared branches)
- git merge preserves both branches' history as-is; git rebase rewrites commit history to appear linear — never rebase commits that are already pushed and shared
- Staging (git add) and committing (git commit) are separate steps on purpose — staging lets you build a commit from only part of your working changes
- git stash is the safe way to set aside uncommitted work temporarily without committing it
Checking state
git status shows staged, unstaged, and untracked changes — run it before almost any other command. git diff shows unstaged changes; git diff --staged shows what's staged and ready to commit. git log shows commit history; git log --oneline --graph gives a compact visual of branch structure.
git status
git diff
git log --oneline --graph --allStaging and committing
git add <file> stages a specific file; git add -p lets you stage individual hunks within a file interactively, which is the right tool when you've made multiple unrelated changes and want separate, focused commits. git commit -m "message" commits what's staged; git commit --amend edits the most recent commit (only safe if that commit hasn't been pushed/shared yet).
git add -p
git commit -m "Fix off-by-one error in pagination"Branching
git branch lists local branches; git switch -c <name> (or the older git checkout -b <name>) creates and switches to a new branch. git branch -d <name> deletes a branch (fails safely if it has unmerged changes); git branch -D <name> force-deletes it.
git switch -c feature/add-search
git branch -d old-feature-branchUndoing changes: reset vs revert
git reset moves the branch pointer (and optionally staged/working changes) backward — it rewrites history, which is fine on a local branch only you use, but dangerous on a branch others have already pulled, since it can cause their history to diverge unexpectedly. git revert creates a brand-new commit that undoes a previous commit's changes, preserving history — this is the safe choice for undoing something on a shared branch.
git revert <commit-hash>
# vs. only on a local, unshared branch:
git reset --hard <commit-hash>Merging vs rebasing
git merge <branch> combines histories with a merge commit, preserving exactly what happened on each branch. git rebase <branch> replays your commits on top of another branch's tip, producing a linear history — but it rewrites commit hashes, which is why you should never rebase commits that have already been pushed and that others may have based work on.
git merge main # preserves branch history
git rebase main # rewrites your commits on top of mainStashing work in progress
git stash sets aside uncommitted changes (staged and unstaged) without committing them, restoring a clean working directory — useful when you need to switch branches quickly. git stash pop reapplies the most recent stash and removes it from the stash list; git stash list shows all stashed sets if you have more than one.
git stash
git switch main
# ...do something else...
git switch -
git stash popCommon Mistakes to Avoid
- ✗Using git reset --hard on a branch that others have already pulled, causing their local history to diverge
- ✗Rebasing commits that have already been pushed to a shared branch
- ✗Force-pushing (git push --force) without first confirming with collaborators, overwriting their work
- ✗Committing everything with git add -A/. without reviewing git status first, accidentally including unrelated or sensitive files
- ✗Confusing git merge and git rebase outcomes and being surprised by an unexpectedly linear or non-linear history
Frequently Asked Questions
When should I use git revert instead of git reset?▾
Use git revert on any commit that has already been pushed to a shared branch — it creates a new commit undoing the change without rewriting history, so it's safe for collaborators who already have the old commits. Use git reset only on local, unshared branches where rewriting history has no effect on anyone else.
Is rebasing always risky?▾
No — rebasing a local, unpushed branch onto an updated main is a common and safe way to keep history linear before you push. It becomes risky specifically when you rebase commits that have already been shared, since it changes their commit hashes and can conflict with others' work built on the originals.
What's the difference between git add -A and git add -p?▾
git add -A stages all changes (new, modified, deleted files) in one step, which is convenient but risks accidentally staging unrelated or sensitive files. git add -p walks through changes interactively hunk by hunk, letting you build a precise, focused commit — worth the extra step for anything you plan to review carefully.
Related Tools
Related Guides
How to Format SQL Queries Before Code Review
Why unformatted SQL slows down code review, and a consistent workflow for formatting queries so reviewers can spot logic bugs instead of parsing indentation.
npm, Yarn, and pnpm Command Reference
The equivalent commands across npm, Yarn, and pnpm for everyday package management tasks — install, add, remove, run scripts, and update — side by side.
Last reviewed: 2026 · Written and verified by the Dev Utilities team · Editorial policy
Report an issue with this guide →