Git intimidates beginners for an understandable reason: it has more than 150 commands, its error messages assume you know its internals, and one wrong flag apparently destroys your work (spoiler: it almost never does). But daily development uses a dozen commands, and they all make sense once you hold the right mental model. This is the guide we wish someone had handed us early on.

The mental model: three places your code lives

Every confusion about Git dissolves once you internalize its three zones:

  1. Working directory — the files you're actually editing.
  2. Staging area (index) — the shopping cart: changes you've marked for the next commit.
  3. Repository (history) — the permanent record of commits.

git add moves changes from 1→2. git commit moves them from 2→3. That's the entire pipeline. The staging area exists so you can commit part of your changes — the bug fix now, the half-finished refactor later — which is the feature that separates deliberate commits from "committed everything, message: 'stuff'."

The daily dozen

  • git status — what's changed, what's staged. Run it constantly; it's free.
  • git add -p — stage changes hunk by hunk, reviewing each. The single most underused flag in Git; it converts sloppy commits into precise ones and doubles as a self-code-review.
  • git commit -m "..." — commit what's staged.
  • git log --oneline --graph — history at a glance.
  • git diff (unstaged) and git diff --staged (about to be committed) — always know what you're about to commit.
  • git switch -c feature-x — create and move to a branch. Branches in Git are just movable labels pointing at commits — creating one costs nothing.
  • git pull / git push — sync with the remote.
  • git stash / git stash pop — shelve uncommitted work when you must switch context mid-task.

Commit messages worth reading

A commit message is a note to a future debugger — usually future you, at midnight, running git log over unfamiliar history. "fix bug" helps no one. The convention that scales: a short imperative summary line ("Fix duplicate newsletter signups on double-click"), then, when the why isn't obvious, a blank line and a sentence of context. The diff already shows what changed; the message exists to record why.

Getting out of trouble

Everyone eventually commits to the wrong branch, commits too early, or pulls a mess. The recovery kit:

  • Wrong commit message (not pushed): git commit --amend.
  • Committed to the wrong branch (not pushed): git switch correct-branch → git cherry-pick <hash>, then remove it from the wrong branch with git reset --hard HEAD~1 there.
  • Undo a commit but keep the changes: git reset --soft HEAD~1 — history rewinds, your work stays staged.
  • Undo a pushed commit safely: git revert <hash> — creates a new commit that reverses the old one, without rewriting shared history. On shared branches, revert; never reset.
  • "I've lost work": almost certainly you haven't. git reflog shows every position HEAD has occupied — find the hash from before the mistake and git reset --hard <hash>. Committed work is nearly indestructible for 30+ days, even after "deleting" it.

The one habit that prevents most disasters

Commit small and often. A commit is a save point; the pain of every Git disaster is proportional to how much uncommitted work was at stake. Ten small commits per day means any mistake costs minutes. One giant commit per week means every mistake is an emergency. Small commits also make code review humane and git bisect (binary-searching history for the commit that broke something) actually useful — a tool that turns "it worked last month, no idea why it broke" into a ten-minute hunt.

What about rebase, submodules, and the scary stuff?

Learn them when you need them, not before. Interactive rebase tidies local history before sharing; submodules solve a problem you'll know when you have it. The honest secret of professional Git usage is that most seniors use the same dozen commands as juniors — they just commit smaller, write better messages, and know that git reflog exists. Master the daily dozen and you're covered for the overwhelming majority of a working developer's career — and for the Git questions in technical interviews, too.