Git Commands Cheatsheet: 15 Commands You Actually Use
Git has hundreds of options, but day-to-day work clusters around a short list: set up a repo, stage and commit, talk to a remote, branch and merge, and undo mistakes safely. Memorizing flags without a mental model is why people fear reset and abuse force push.
This cheatsheet groups fifteen core commands into a learning path — setup → daily loop → remotes → branches → undo — so each command has a job on the path from working directory to remote. For team branch naming and Git Flow, see [Git Branching Strategy](/blog/git-branching-strategy).
Running example: fix a bug on a feature branch, commit locally, push to origin, and open a PR.
Map: working tree → staging → local → remote
Git moves snapshots through four places. Your working directory holds edits. git add copies them into the staging area. git commit freezes a snapshot in the local repository. git push sends commits to a remote (usually origin on GitHub). git pull brings remote commits back down and merges them into your current branch.
If you only remember one picture, remember that path. Every command below either moves data along it, inspects it, or rewinds a step.
Quick reference
- Working dir → staging:
git add - Staging → local history:
git commit - Local → remote:
git push - Remote → local:
git pull(fetch + merge) - Inspect anytime:
git status,git diff
Remember this
I can place add, commit, push, and pull on the working → staging → local → remote path.
Setup: init, clone, and config
git init creates a new repo in the current folder (a hidden .git). git clone copies an existing remote repo — history, branches, and an origin remote already set. git config sets identity and defaults (user.name, user.email, editor, aliases) globally or per repo.
Start with clone when the project already lives on GitHub. Use init for greenfield work, then git remote add origin … and push. Misconfigured name/email shows up as messy history on every commit — fix config before your first real commit.
Quick reference
git init— new local repo in cwd.git clone <url>— full copy +origin.git config --global user.name/user.email— who you are on commits.- Prefer
--globalfor identity; override per-repo when needed. - Practice: clone a public repo and run
git remote -v.
Remember this
I know when to init vs clone and how config sets commit identity.
Daily loop: status, add, diff, commit
git status shows modified, staged, and untracked files — check it before every commit. git diff shows unstaged changes; git diff --staged shows what will go into the next commit. git add (paths or .) stages for commit. git commit -m "…" records a snapshot with a message.
Small, focused commits beat giant end-of-day dumps. Status → diff → add → commit is the muscle memory loop; skip status and you commit secrets or leftover debug files.
Quick reference
git status— what changed / staged / untracked.git diff/git diff --staged— see the actual patch.git add <file>orgit add .— stage.git commit -m "message"— save locally.- Never commit
.envor secrets — check status first.
Remember this
I can run status → diff → add → commit as a safe daily loop.
Remotes: remote, push, and pull
git remote lists or manages remotes (git remote -v, git remote add). git push uploads local commits to a remote branch. git pull fetches from the remote and merges into your current branch (fetch + merge in one step).
Push your feature branch often so backups and CI see it. Pull (or fetch + rebase) before long pushes on shared branches to avoid surprise conflicts. Force-push to main is almost never the right answer — prefer new commits or a careful force-with-lease on your own feature branch only when you know the team rules.
Quick reference
git remote -v— see fetch/push URLs.git push -u origin HEAD— publish current branch.git pull— update current branch from remote.- Push is local → remote; pull is remote → local.
- When to skip pull: if you need a pure fetch before deciding merge vs rebase.
Remember this
I can explain push vs pull and list remotes with git remote -v.
Branches: branch, checkout, and merge
git branch lists branches or creates one (git branch feature/x). git checkout (or modern git switch) moves your working tree to another branch; with paths it can restore files. git merge brings another branch’s commits into the current branch.
Typical flow: create/switch to feature/bugfix, commit work, push, open PR, merge via the host (or merge locally into develop/main per team policy). Deep strategy — main vs develop, release, hotfix — lives in the branching strategy guide.
Quick reference
git branch— list / create / delete branches.git checkout <branch>orgit switch <branch>— change branch.git merge <branch>— combine into current branch.- Prefer PRs for shared mainline merges.
- Delete merged feature branches to reduce noise.
Remember this
I can create a branch, switch to it, and merge work back.
Undo safely: stash and reset
git stash shelves dirty work without a commit so you can switch branches cleanly; git stash pop restores it. git reset moves the branch pointer — --soft keeps changes staged, --mixed (default) keeps them unstaged, --hard discards working tree changes. Hard reset on shared history is dangerous.
When to stash: context-switch with unfinished edits. When to reset: fix the last local commit before push (--soft / --mixed). When not to: rewriting commits already pushed to a shared branch without team agreement.
Quick reference
git stash/git stash pop— temporary shelf.git reset --soft HEAD~1— undo commit, keep staged.git reset HEAD~1— undo commit, keep edits unstaged.git reset --hard— discard — confirm twice.- Practice: stash, switch branch, pop — then soft-reset a local commit.
Remember this
I know stash for dirty work and which reset mode keeps or drops changes.
These fifteen commands — pull, status, init, push, config, reset, commit, clone, diff, merge, remote, add, stash, checkout, branch — cover almost every daily Git session. Learn them as jobs on the path from working tree to remote, not as isolated trivia.
Your homework: in a scratch repo, run init → config check → add/commit → branch/checkout → merge → remote add + push (to a throwaway GitHub repo) → stash/reset once each. Then read [Git Branching Strategy](/blog/git-branching-strategy) for how teams organize those branches in production.
Related Articles
Explore this topic