Git Commands Cheat Sheet — Daily Workflows That Stick

(Updated: July 16, 2026 ) Git Version control CLI Productivity

Git documentation is huge; day-to-day work uses a smaller vocabulary. This cheat sheet groups commands by job, with safety notes. Prefer reading git status before fancy history rewrites — most “Git emergencies” are recoverable if you have not force-pushed yet.

Start and inspect

git clone <url>
git status
git log --oneline --graph --decorate -20
git diff
git diff --staged

status tells you which commands make sense next. diff without --staged shows unstaged work; with --staged shows what the next commit will contain.

Stage, commit, amend (carefully)

git add path/to/file
git add -p                  # stage hunks interactively
git commit -m "Explain why"
git commit --amend --no-edit  # only if commit not pushed / you own it

Write commits for humans: why the change exists. Avoid git commit -a when secrets or unrelated files are sitting dirty. Do not amend commits already on a shared remote unless your team explicitly allows it.

Branches

git switch -c feature/login   # create + switch
git switch main
git branch -d feature/login   # delete merged local branch
git branch -vv                # tracking info

Name branches by intent (fix/, feat/). Keep main releasable.

Remotes and sync

git fetch origin
git pull --ff-only            # fail instead of surprise merge
git push -u origin HEAD
git remote -v

fetch updates remote-tracking refs without changing your working tree. Prefer explicit fetch + inspect + merge/rebase over blind pull when history looks weird.

Merge vs rebase (team norms matter)

git merge main                # while on feature branch
git rebase main               # replay your commits on tip of main

Merge preserves true history and is safer for shared branches. Rebase linearizes — great for local feature branches, painful if you rebase commits others already based work on. After a local rebase: git push --force-with-lease (not bare --force) when updating a personal remote branch.

Stash for context switches

git stash push -m "wip: login css"
git stash list
git stash pop

Stash is local duct tape. Do not stash secrets thinking they are encrypted. For longer parking, commit to a WIP branch instead.

Undo without panic

GoalSafer approach
Unstage a filegit restore --staged file
Discard unstaged editsgit restore file (destroys work!)
New commit that reverses a pushed onegit revert <sha>
Move branch pointer locallygit reset --soft/--mixed before push
Find lost commitsgit reflog

reset --hard and force-push to shared main are the classic footguns — avoid unless the team protocol says so.

Tags and releases

git tag -a v1.2.0 -m "Release 1.2.0"
git push origin v1.2.0

Annotated tags mark releases; lightweight tags are pointers. CI often keys off tags.

Useful diagnostics

git blame path/to/file
git show <sha>
git cherry-pick <sha>
git bisect start              # binary search a regression

bisect plus a test script turns “which commit broke prod?” into a short hunt.

.gitignore and accidents

echo .env >> .gitignore
git rm --cached .env          # stop tracking without deleting local file

If a secret was committed, rotate the secret; removing from history is secondary and incomplete without rotation.

Suggested daily loop

  1. git switch -c … from updated main
  2. Small commits with clear messages
  3. git fetch + rebase/merge per team rule
  4. PR push with --force-with-lease only on your branch after rebase
  5. git switch main && git pull --ff-only after merge

Bottom line

Master status/diff/log, branch, commit, fetch, and a team-approved merge or rebase path. Use stash for short interruptions, revert for public undos, and reflog when something “disappears.” Git rewards boring discipline more than memorizing every subcommand.