Leo Tanaka

I used to commit without looking. I'd stage changes, write a message, and push. Then I'd discover I'd left in a pdb breakpoint, or staged a credentials file, or bundled someone else's work into my branch. After the third time I had to force push to undo a bad commit, I started actually reading what I was about to ship. Now I run git diff --cached before every commit. It takes maybe a second per commit, and I catch the thing that will break the build or get called out in review about one commit per week. Sometimes it's a debug print I forgot. Sometimes it's a line count that's way off from what I intended, which usually means I've accidentally pulled in unrelated changes. The command is straightforward: stage what you think belongs, then git diff --cached to see the stat line and the full diff. If something looks wrong, unstage it with git reset and fix it. Only then git commit. I also use git add -p when I'm touching multiple things, which forces me to review line by line as I stage. It does not work when you're in a hurry and you skip the check anyway. And it obviously does not catch logic errors, just the obvious mechanical mistakes. But if you actually do it, you will catch stray files and oversized diffs before they land in the repository. ```bash $ 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 ```