Why do I have to commit so much?

For a long time my commits were notes to myself.

ok. test. hopefully this works. The change was in the repo. Weeks later I often could not tell what I had actually done.

So I took it more seriously. Clearer messages. What changed — and why. For a while that worked. It felt like I was learning to build software “properly” on the side of the real job.

Then it slipped again.

Not because I forgot how. The business was simply louder. When something has to get done, a clean commit history starts to feel like extra work. I still know what a good message looks like. I do not always write one.

At some point the sentence sat in my head — and later in a commit message: Why do I have to commit so much?

It was not about git.

It was about the gap between the developer I thought I should be and the managing director who needs something useful under time pressure. When there is room, I leave a cleaner trail. When there isn’t, it ships. Pretending I am always disciplined would be a lie.

I still think clear commits are useful. They help me when I look back later. But a streak of clean messages does not prove anything to me anymore. Proof is when the thing works for the people who need it.

If you code while running a business, you may know this: you learn the “right” way — and drop it again as soon as things get loud. Both belong. The history is not the product.

AI makes it weirder. It can write a polished commit message for a change I barely understand. That does not help me. I want to know what broke — even if the message is just ok.