Ten things about Git that actually matter

I spent August writing an 80-page Git and GitHub reference, every command, both the CLI and the browser, from git init to branch protection rules. Then I did the useful part: I asked what I'd keep if I could only keep one page.

This is that page. Ten ideas, in rough order of how much grief each one saves.

1. A branch is a pointer to a commit

Not a copy of your files. Not a folder. A 40-character file containing a commit hash.

Once that lands, most of Git stops being mysterious. Creating a branch is instant because it writes 41 bytes. Deleting one doesn't delete work, it deletes a pointer, the commits are still there, which is exactly why reflog can rescue them. Merging is Git working out what changed since two pointers last agreed.

Every Git tutorial should open with this sentence and most open with git add.

2. Run git status and git log --graph before every decision

Never guess what state you're in. Guessing is how people run git reset --hard on the wrong branch.

git log --oneline --graph --all is the single most useful command in Git, because it makes the shape of history visible, and Git's real difficulty is that history is a graph while your mental model is a list.

3. Commit small, commit often

Uncommitted work is the only work Git cannot recover.

Everything else, bad merges, wrong branch, force-pushed history, deleted branches, botched rebases, is recoverable. That's the whole trade. Commit frequently and you buy yourself an undo button for everything else you're about to do.

4. git reflog recovers almost anything

Learn it before you need it, because you'll need it while panicking.

git reflog                    # every position HEAD has held
git reset --hard HEAD@{3}     # go back to where you were three moves ago

A "lost" commit after a bad reset or rebase is usually thirty seconds of work to recover. Most people don't know this and redo the work instead.

5. Never rewrite public history

Rebase your own branches. Revert on shared ones.

The rule isn't aesthetic. Rewriting a branch other people have pulled means their next pull produces a merge between two versions of the same work, and someone spends an afternoon untangling it. The cost lands on your teammates, not on you, which is precisely why the discipline has to be a rule rather than a judgment call.

6. --force-with-lease, never --force

--force says "make the remote look like me." --force-with-lease says "make the remote look like me, unless someone else pushed since I last looked, in which case stop."

Same keystrokes, one of them refuses to destroy a colleague's work. There is no situation where plain --force is the better choice; there are only situations where you got away with it.

7. Write commit messages that explain why

The diff already shows what changed. It cannot show what you were thinking.

bad:  fix bug
ok:   fix null check in user parser
good: guard against null email in user parser

      The SSO provider omits email entirely for service accounts,
      which crashed the nightly sync. Defaulting to empty string
      rather than skipping the row, so the account still appears
      in the audit export.

The primary reader of that message is you, in eleven months, wondering why this looks wrong. Write for that person.

8. Keep pull requests under 400 lines

Review quality falls off a cliff past roughly that size. Beyond it you don't get review, you get approval, a reviewer skims, sees nothing obviously broken, and clicks the button.

A 900-line PR isn't twice as hard to review as a 450-line one. It's unreviewable, and everyone involved quietly agrees to pretend otherwise.

9. When a secret leaks: rotate first, clean history second

The instinct is to scrub the commit and hope nobody noticed. That's the wrong order, and it's a comforting kind of wrong.

The moment a key is pushed to a remote, assume it is compromised. Scanners crawl public commits within minutes, and rewriting history does nothing about a copy someone already has, a fork, or GitHub's own cached views of the deleted commit.

So: revoke and rotate at the provider first. That's the step that actually ends the exposure. Cleaning history afterwards is hygiene, not remediation, worth doing, but it protects nothing on its own. Then add gitleaks as a pre-commit hook so the next one never lands.

10. Automate the rules, branch protection beats team discipline

Every convention that depends on people remembering it will be broken on a deadline. Not because anyone is careless, but because deadlines are exactly when discipline is scarcest.

Encode the rule instead. Required status checks, required reviews, protected branches, a CI job that fails the build. A rule a machine enforces is a rule; a rule in a wiki is a preference.

The through-line

Six of these ten are really the same idea: make the safe path the easy path. --force-with-lease over --force, small commits over careful ones, branch protection over team etiquette, a hook over a habit.

Git is powerful enough to let you destroy things, and no amount of care scales as well as a guardrail that makes destruction take an extra step. Design your workflow so the tired, rushed version of you can't do much damage, because that's the version of you that will be using it when it matters.