Git Commands Every Developer Uses Daily — My Cheatsheet

I'm Safdar Ali, a frontend engineer in Bengaluru. Posters listing 100 git commands help nobody. This cheatsheet is the 20 commands I run weekly on React and Next.js repos — with examples, not alphabet soup. If you search "git commands cheatsheet," you want something you can pin next to your terminal, not a Wikipedia page.

Git is version control for fear — fear of losing work, fear of breaking main, fear of code review. These twenty commands cover ninety percent of my terminal history on React and Next.js repos. The rest is git help and Stack Overflow for edge cases. If you are interviewing for frontend roles in India, expect a live question about branching or fixing a bad commit; this cheatsheet is your rehearsal script.

20 git commands — cheatsheet table

Pin this table next to your monitor or save as a PDF. The Example column is copy-paste ready — replace branch names and file paths with yours. Commands like cherry-pick and bisect appear monthly, not daily; they are here because production fires do not wait until you remember syntax.

One-time setup — identity and default branch

git config --global user.name "Safdar Ali"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main
git config --global pull.rebase true   # cleaner history on pull

SSH keys for GitHub save password prompts — generate with ssh-keygen, add to GitHub settings, clone with git@github.com URLs. HTTPS with credential manager works too; pick one per machine.

Daily flow — morning to PR

git switch main
git pull --rebase origin main
git switch -c feat/blog-performance-checklist
# ... edit files ...
git status -sb
git add app/blog/web-performance-checklist-2026/page.tsx
git commit -m "feat(blog): add web performance checklist 2026"
git push -u origin feat/blog-performance-checklist

I use conventional commits on team repos — scopes like feat(blog) make changelogs readable. Solo portfolio commits can be simpler; consistency matters more than the exact prefix.

Pull with rebase before starting work — your feature branch stays on top of main without merge commits that clutter history. Push with -u on first push so future git push works without arguments. Small commits make bisect and revert possible; one giant commit titled "fixes" helps nobody when production breaks at 11 PM IST.

BEFORE / AFTER — fixing the wrong commit message

# BEFORE — panic amend after push (rewrites history on shared branch)
git commit --amend
git push --force   # hurts teammates

# AFTER — not pushed yet: soft reset one commit
git reset --soft HEAD~1
git commit -m "fix(blog): correct performance checklist date"

# AFTER — already on main: revert (safe, auditable)
git revert abc1234
git push origin main

Rebase vs merge — what I use on Next.js teams

Feature branches: rebase onto main before PR for a linear history. Long-lived branches or open PRs with many reviewers: merge main in to avoid force-push churn. Never rebase commits other people already pulled.

git fetch origin
git rebase origin/main
# conflict in page.tsx — fix file, then:
git add app/blog/some-post/page.tsx
git rebase --continue

stash — context switching without junk commits

git stash push -m "half-done framer motion"
git switch main
git pull --rebase
git switch feat/animations
git stash list
git stash pop   # apply latest — resolve conflicts if any

Production hotfix while mid-feature? Stash, branch from main, fix, push, then return. Cleaner than WIP commits titled "temp".

Git + React/Next.js — files you touch every day

On Next.js projects I commit page.tsx files per route, shared components, and lib/ utilities separately. Lockfile changes get their own commit so bisect can isolate dependency regressions. Never commit .env — add to .gitignore on day one; rotate keys if accidentally pushed.

# See what changed in App Router only
git diff --stat app/

# Discard local experiment in one component
git checkout origin/main -- components/Hero.tsx

# Stage only performance-related hunks
git add -p app/blog/web-performance-checklist-2026/page.tsx

Undo mistakes — restore, reset, revert

# Unstage everything, keep file edits
git restore --staged .

# Throw away local edits in one file (careful)
git restore components/Header.tsx

# Undo last commit, keep changes staged
git reset --soft HEAD~1

Aliases that save keystrokes

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.st "status -sb"
git config --global alias.lg "log --oneline --graph -20"

Pair git with Cursor + Claude workflow — AI generates diffs, you still own commit messages and branch hygiene.

Pull request workflow — log and diff before review

# See what you are about to push
git log origin/main..HEAD --oneline
git diff origin/main...HEAD --stat

# Interactive staging — split hunks when one file has two fixes
git add -p lib/api.ts

Reviewers in Bengaluru product teams often work async. A clean commit history with one logical change per commit makes revert and bisect possible when production breaks at 11 PM IST.

git bisect — find the commit that broke the build

git bisect start
git bisect bad                    # current main is broken
git bisect good v1.3.0            # last known good tag
# test, then mark each step:
git bisect good   # or: git bisect bad
git bisect reset  # when done

I used bisect twice in 2025 on Next.js upgrades — a dependency bump broke SSR. Faster than reading fifty commits manually.

Tag releases on client projects — v1.4.0 gives support a reference when users report bugs. Pair tags with GitHub Releases notes listing Lighthouse scores or migration steps. Future you will thank present you when comparing bundle size between v1.3.0 and v1.4.0.

Merge conflicts — keep calm, re-read the diff

# After conflict markers appear in file:
git status                    # lists unmerged paths
# edit file — remove <<<<<<< ======= >>>>>>>
git add path/to/resolved.tsx
git rebase --continue         # or git merge --continue

Conflicts in package-lock.json or pnpm-lock.yaml: often easier to regenerate lockfile than merge by hand. Delete lock, install fresh, commit — document in PR why.

Learn git by shipping, not memorising

Run this cheatsheet on your next feature branch. Break something in a throwaway repo — reset, restore, rebase until it feels boring. That boredom is seniority.

Pin this article in your team Slack when onboarding juniors. Git is the safety net under every React deploy — Vercel rollback fixes production, but git history explains why the bug shipped.

I keep this cheatsheet open during code review. When a PR has twelve commits titled "fix," I ask the author to squash with interactive rebase before merge — readable history is a gift to the next engineer on call.

# Squash last 5 commits into one before merge (unpushed branch)
git rebase -i HEAD~5
# mark pick on first, squash on rest, write one message

Related: Promises vs async/await. Contact: safdarali.in/contact.

GitHub CLI complements terminal git: gh pr create, gh pr checkout, gh run watch for CI. On client repos I never merge red CI — Lighthouse budget failures are merge blockers same as failing tests. Attach checklist screenshots from the performance article in PR bodies so reviewers see evidence, not claims.

Fork workflow for open source: fork, clone your fork, add upstream remote, branch, push to origin, open PR to upstream main. git remote -v should show both origin and upstream. Sync fork with upstream main before new feature branches — fewer surprise conflicts on long-lived OSS contributions.

Security: never commit API keys, .env.local, or service account JSON. git filter-repo or BFG cleans history if you leaked secrets — rotate keys immediately. Pre-commit hooks with gitleaks run in two minutes to install and save careers. Indian startups have lost production databases to committed credentials; git is not only logistics, it is risk management.

Monorepos add git complexity — learn git sparse-checkout if you only touch apps/web. Turborepo and Nx do not replace git fundamentals; they orchestrate tasks on top of branches you still manage with pull and rebase. One bad force-push on shared main still ruins everyone's afternoon regardless of monorepo tooling.

On-call playbooks should list git revert before hotfix branch when main is broken — revert is fast and auditable. Hotfix branches from tags work when you need a patch on an older release line. git tag -l and git checkout v1.3.0 -b hotfix/1.3.1 are commands you want muscle memory for before the incident, not during it.

Teaching git to juniors: pair on one feature branch end-to-end — branch, commit, push, PR, address review, merge. Cheatsheet on second monitor. Forbidden until week two: force push, rebase on shared branches, commit --no-verify. Week three introduces stash and cherry-pick. Competence is reps, not flashcards.

.gitignore templates for Next.js should include .next, node_modules, .env*, and OS junk. Commit .gitignore before first real file — history is cleaner. git check-ignore -v path/to/file explains why something is ignored when uploads fail.

Release tags pair with changelogs: git log v1.3.0..v1.4.0 --oneline gives marketing bullet points. Automate with release-please or semantic-release when team size justifies it; solo portfolios can stay manual with disciplined tags.

The git commands cheatsheet is not glamourous — neither is brushing teeth. Daily hygiene prevents emergencies. Run status before lunch and before standup; know your branch; push WIP to remote backup branches if you fear laptop failure. Bengaluru traffic is unpredictable; so are laptops left in auto-rickshaws.

git worktree add ../hotfix main creates a second checkout folder — useful when you must patch production while a messy feature WIP sits in your primary directory. Remove with git worktree remove when done. Advanced, but worth knowing before the incident.

Blame is archaeology, not punishment: git blame -L 40,60 path/to/file.tsx shows who last touched lines — context for refactors, not scorekeeping. Pair blame with git log -p for the full story when debugging a regression introduced three months ago on a marketing page you now maintain.

Print the twenty-row table, tape it above your monitor, and delete bookmarks to hundred-command posters. Depth on twenty beats anxiety about five hundred you will never run. Git competence compounds like compound interest on career safety — boring until you need it, then priceless.

Every command in the table above earned its row by appearing in my shell history at least twice in one month — not by filling space. Add commands to your personal fork of this cheatsheet when you use them repeatedly; prune rows you never run. A cheatsheet is a living document, not a poster. Update yours quarterly from git reflog exports if you want data-driven rows.

Git commands cheatsheet users ask me about most in DMs: how to undo last commit, how to sync fork, how to fix wrong branch. Those three flows are covered above in before-after, daily flow, and revert sections — start there before searching hundred-command posters online. Run git status now — know your branch before you read the next article on this blog.

Twenty commands, daily habit, fewer production scares — the git commands cheatsheet promise in three clauses. Keep it open next to your terminal until status and pull feel automatic every single day.