Git Without the Fear: A Practical Mental Model

Git feels scary because most tutorials teach commands before they teach the model underneath them. Once the model clicks, the commands stop being magic incantations and start making sense.

Three things, not one

Git tracks three areas: your working directory (the files you're editing), the staging area (what you've marked to include in the next commit), and the repository history (commits you've already saved). Almost every confusing Git moment comes from losing track of which of these three you're actually looking at.

git status        # shows the difference between all three areas
git diff           # working directory vs. staging area
git diff --staged  # staging area vs. last commit

A commit is a snapshot, not a diff

It helps to stop thinking of commits as "changes" and start thinking of them as full snapshots of your project at a point in time, linked back to the snapshot before it. That's why you can jump to any commit and get a complete, working version of your code — Git is just showing you the difference for convenience.

Branches are just labels

A branch is nothing more than a movable pointer to a commit. Creating a branch is instant and cheap because Git isn't copying any files — it's just adding a new label. This is why experienced developers create branches constantly and without hesitation.

git branch feature/new-thing   # create the label
git checkout feature/new-thing # move HEAD to point at it
# or, in one step:
git switch -c feature/new-thing

The three commands that undo mistakes

• git restore <file> — discard uncommitted changes in your working directory.
• git reset --soft HEAD~1 — undo the last commit but keep your changes staged.
• git revert <commit> — safely undo a commit that's already been pushed, by adding a new commit that reverses it.

Reset rewrites history; revert adds to it

The rule of thumb: use reset freely on commits only you have seen, and use revert once anyone else might have already pulled those commits — rewriting shared history creates painful conflicts for your teammates.

Merge conflicts are just disagreements

A conflict means two branches changed the same lines differently, and Git is asking you to decide which version wins. Open the file, look for the <<<<<<< markers, choose (or combine) the correct content, delete the markers, then stage and commit like normal.

The takeaway

Git isn't a list of commands to memorize — it's a small, consistent model of snapshots and movable pointers. Learn the model once, and the commands become obvious.