Read the diff stat before you commit literally anything

I used to commit whatever was staged, which sounds efficient until you realize that efficiency in the wrong direction just means you commit faster. I'd push a branch with three test files still in there, or a package-lock.json file I never meant to touch, or worse: a five hundred line refactor when I'd sworn I was only fixing the bug. The commit would land, someone would ask why that one change was in there, and I'd have to squint at GitHub and pretend I had a reason.

So now I run git diff --stat before every single commit. It takes about one second. I read through the stat line, check the file count, verify the numbers make sense for what I thought I was doing, and then I commit. That's it. The tool is just git. The discipline is knowing that one second now saves five minutes of explaining later.

The concrete detail is the stat line itself. git diff --stat shows you file names and the number of added and deleted lines in a tiny ASCII chart. If I see a node_modules change or a lockfile in there, I know I'm about to make a mistake. If I see a file I don't recognize, I stop and figure out why it's there. If the numbers don't match my intent, I unstage and re-sort what I'm actually committing.

The caveat is that this only works if you're committing conscious changes. If you're in the middle of a refactor where you're genuinely touching forty files at once, the stat line won't save you. You still need to have structured your work so that you know what belongs together. This is a safety rail, not a strategy.

$ git diff --cached --stat
 internal/handler/move.go      | 18 +++++++++---
 internal/handler/move_test.go | 42 ++++++++++++++++++++++
 .env.local                    |  3 +++
 3 files changed, 60 insertions(+), 3 deletions(-)
$ git restore --staged .env.local