Git Commands Cheatsheet: 15 Commands You Actually Use

Q: Daily loop: status, add, diff, commit

Skipping git status before a commit is how secrets and leftover debug files end up staged — status → diff → add → commit is the loop that catches them first.

Q: Undo safely: stash and reset

reset --soft keeps changes staged, --mixed unstages them, --hard discards them outright — and any of the three on commits already pushed to a shared branch rewrites history out from under a teammate.

Core Concept LearningJuly 16, 20265 min readUpdated July 21, 2026

Git has hundreds of options, but daily work clusters around a short path: inspect an edit, stage it, commit it, publish a branch, and undo mistakes without losing work. Memorizing flags without that model is why reset and rejected pushes feel dangerous.

This cheatsheet follows one login-timeout fix from a new branch to origin, then recovers from accidental staging and a non-fast-forward push. For team branch rules rather than command mechanics, see Git Branching Strategy. Once the branch is published, CI/CD with GitHub Actions explains how commits become tested deployments.

Git workflow: working directory to staging to local repo to remote

Learning path

Follow these checkpoints in order — each builds on the last.

Every Git command either moves a snapshot along working tree → staging → local → remote, inspects it, or rewinds one step — there's no fifth thing to memorize.
Misconfigured name or email shows up as messy history on every future commit — fix git config before the first real commit, not after tracking down whose commit that was.
Skipping git status before a commit is how secrets and leftover debug files end up staged — status → diff → add → commit is the loop that catches them first.
Pulling before a long push on a shared branch is what turns a surprise conflict into a routine fetch-and-rebase — push is local→remote, pull is remote→local, and force-push to main is almost never the fix.
A feature branch exists to isolate work until a PR merges it back — delete it once merged, or branch noise accumulates until nobody can tell which ones are still active.
reset --soft keeps changes staged, --mixed unstages them, --hard discards them outright — and any of the three on commits already pushed to a shared branch rewrites history out from under a teammate.

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

Every Git command either moves a snapshot along working tree → staging → local → remote, inspects it, or rewinds one step — there's no fifth thing to memorize.

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.

Setup commands: init, clone, config

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 --global for identity; override per-repo when needed.
Practice: clone a public repo and run git remote -v.

git initgit clonegit config

Remember this

Misconfigured name or email shows up as messy history on every future commit — fix git config before the first real commit, not after tracking down whose commit that was.

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.

One commit zoom: .env staged by mistake → restore --staged → file stays local

Quick reference

git status — what changed / staged / untracked.
git diff / git diff --staged — see the actual patch.
git add <file> or git add . — stage.
git commit -m "message" — save locally.
Never commit .env or secrets — check status first.

git statusgit addgit diffgit commit

Record one focused bug fix

1git switch -c fix/login-timeout2git status --short3git diff4git add src/login.ts5git diff --staged6git commit -m "Fix login timeout handling"

Recover an accidentally staged secret

1# Unstage without deleting the local file2git restore --staged .env3printf ".env\n" >> .gitignore4git add .gitignore5git status --short

Remember this

Skipping git status before a commit is how secrets and leftover debug files end up staged — status → diff → add → commit is the loop that catches them first.

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.

Remote commands: remote, push, pull

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.

git remotegit pushgit pull

Publish the current feature branch

1git remote -v2git push -u origin HEAD

Recover from a rejected push

1# Remote main moved; replay your local commit on top2git fetch origin3git rebase origin/main4# If Git stops: edit conflicts, then continue5git add <resolved-file>6git rebase --continue7git push -u origin HEAD

Remember this

Pulling before a long push on a shared branch is what turns a surprise conflict into a routine fetch-and-rebase — push is local→remote, pull is remote→local, and force-push to main is almost never the fix.

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.

Branching commands: branch, checkout, merge

Quick reference

git branch — list / create / delete branches.
git checkout <branch> or git switch <branch> — change branch.
git merge <branch> — combine into current branch.
Prefer PRs for shared mainline merges.
Delete merged feature branches to reduce noise.

git branchgit checkoutgit merge

Remember this

A feature branch exists to isolate work until a PR merges it back — delete it once merged, or branch noise accumulates until nobody can tell which ones are still active.

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.

Undo commands: reset vs stash

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.

git stashgit reset

Remember this

reset --soft keeps changes staged, --mixed unstages them, --hard discards them outright — and any of the three on commits already pushed to a shared branch rewrites history out from under a teammate.

Key takeaway

These fifteen commands cover most daily Git sessions because each one inspects or moves work between the working tree, staging area, local history, and remote.

Practice (20 min): Create a scratch repo, commit one file on main, make a login-timeout fix on a branch, and merge it; the expected result is a clean tree with both commits visible in git log --oneline --graph. Intentionally stage .env and, with a throwaway remote if available, create a non-fast-forward push rejection. Recover with git restore --staged .env plus fetch/rebase before pushing. Pass when no secret file is committed, the branch publishes without force, and you can identify where each snapshot lived after every command.