The Mistakes That Bite Beginners

Four mistakes account for most of the real damage beginners do with Git. All four are avoidable by a habit that costs seconds, and all four are worth reading about before you meet them rather than afterwards.

Notice the pattern as you go: in every case Git did exactly what it was told. None of these is a bug, and none of them is prevented by being careful. They are prevented by a habit.

1. Committing a secret

What happens. An API key, a password or a token ends up in a committed file — usually swept in by git add . along with everything else.

What it costs. The moment it is pushed, treat the credential as compromised. Removing the file later does not help: every earlier commit still contains it, and anyone with the repository can read it there. GitHub scans public repositories for leaked credentials automatically, and its own advice when one turns up is to rotate it immediately.

The habit. Write .gitignore before the first commit, and read what git status lists before running git add .. If it happens anyway: rotate first, then git rm --cached, exactly as in Chapter 5.

2. Committing something enormous

What happens. A video, a dataset, or a folder of installed dependencies gets committed. Often it is node_modules, and often it is thousands of files at once.

What it costs. Every clone of that repository carries it forever, because clones bring the whole history. Removing it from the current state does not shrink anything; the file is still in the commits behind you.

The habit. Ignore dependencies and build output on day one. And look at the file count when git status reports it — "3,412 files changed" is not a thing that should ever surprise you.

3. Working directly on main

What happens. Three unrelated changes end up half-finished on the branch that is supposed to hold the working version.

What it costs. None of them can be undone separately, none can be proposed for review, and the version everyone treats as real is broken until whichever one you are furthest through gets finished.

The habit. Branch first, always, even alone, even for a ten-minute change. It is one command, and it is the one that keeps the other three from tangling.

4. Force-pushing over shared work

What happens. A push is rejected, a forum says to add --force, and it works.

What it costs. The branch on GitHub is replaced with yours. Any commit that was there and not on your machine is no longer part of that branch — which, on a shared branch, is somebody's afternoon, and they will find out by discovering their work missing.

The habit. Pull, resolve, push. That is the answer to a rejected push every single time in this book. --force has legitimate uses on a branch nobody else touches, and none of them are things a beginner needs.

All four have near-misses in Sandpiper's story. The club's phone list, committed in week one and cleaned up in Chapter 5. A folder of full-resolution bird photographs that very nearly went in with a careless git add .. An afternoon where three changes were tangled together on main before branching became a habit. And the rejected push in Chapter 7 that a forum would have answered with --force.

The pattern behind all four

In every case Git faithfully did what it was told. Nothing malfunctioned, and no warning was suppressed.

Three of the four are prevented by the same two-second act: reading what git status says before doing something irreversible. The fourth is prevented by not copying a command you do not understand from a forum.

That is the entire safety story of this book, and it is why Chapter 4 is arranged the way it is: diagnose first, type second.