What git add -p Taught Me About Committing

I used git add . for years and never really questioned it. It was just the thing you do once the code works. Fix the bug, run the tests, stage everything, commit, move on. Nothing exploded, so I assumed it was fine.

Looking back, most of my commits were basically "whatever I touched in the last hour," and I did not think much about whether those changes actually belonged together.

The Discovery

I only learned about git add -p today, and it was one of those small things that made me realize I have been slightly careless without noticing. Being forced to look at each hunk and decide yes or no made me realize how often I mix unrelated changes together. A bug fix plus a rename, plus some formatting, plus a debug line I forgot to remove.

git add . made that easy, and because it was easy, I kept doing it.

The Perspective Shift

What really clicked for me was thinking about future me or anyone else trying to read the history. When something breaks and you have to bisect or revert, a big messy commit is just pain. With interactive staging, each commit feels like it has a single reason to exist. It is slower, but in a way that feels intentional instead of annoying.

I am not saying git add . is bad or that I will never use it again. But learning git add -p made me realize that committing is not just a cleanup step after coding. It is part of how you communicate what you were trying to do.

Once I noticed that, it became hard to unsee how much meaning I was throwing away by always staging everything at once.