If more than half of your commits are “feat” ones, you’re doing something wrong

I counted the distribution of my commits by type and the result was enlightening!

Before starting the numbers, let’s get to the same page:

Git

You’re using Git, right? And, do I need to even explain what it is?

Also, if you’re using some more modern VCS (version control system), then you probably have a good reason. But if you’re still using some older tool… changing shouldn’t be that hard (I know because I had to convert multiple SVN repos to Git some years ago and never looked back).

However… if you’re not using any or you think you’re using them because you’re leaving things in Dropbox… are you ok? Do you need to talk?

Atomic Commits

Committing became a routine more complex than just doing a bunch of stuff and adding a “small changes” message.

I carefully check everything I did, splitting it into smaller commits, naming and describing what’s happening with care. It’s to the point some commits have only one line and I don’t shy away from committing line by line from a file if that’s what it takes, not only that, I had multiple commits where the changes were smaller than the message.

This pays out when you are able to navigate commit by commit with the messages as a commentary of what and sometimes why you did that.

Conventional Commits

This is a specification on how to commit something and you probably saw it in the wild or in big projects. It usually goes with “something”(optional scope): message (that has a header but can also include a body and footer). The “something” there, among others, is usually: feat (feature), fix, refactor, or test.

First, how about you?

What do you think you would see if you counted yours?

The reason why I went counting was that I had a hunch that more than half of my commits were refactoring because I refactor stuff a lot.

I don’t believe in having perfect code from the get-go, but even a little refactoring can go a long way to make something a lot more pleasant to read and maintain and would like to show that to colleagues that might not care as much about the code as I do.

The count!

| Type     | Count | Percentage |
| ---      | ---   | ---        |
| fix      |  104  |   7%       |
| feat     |  568  |  38%       |
| refactor |  322  |  22%       |
| test     |  291  |  19%       |
| OTHER    |  212  |  14%       |
| ---      | ---   | ---        |
| TOTAL    | 1497  | 100%       |

These are the numbers I got after summing commits from the front and backend projects I’m working on right now. On the “other” there are things like docs, chore, build, and others with only a couple of commits.

Between the back and front, there were some differences, but I know that I usually already commit a feat of “use cases” along with a lot of tests because the tests help me shape the “use cases” and I refactor a whole lot more in the frontend because there’s a lot of components and I move them all the time. Even then, it was just a few percentage points, and overall the distribution is pretty much that.

After the count

Unfortunately, there’s no way, or at least it would be a hard endeavor to actually calculate the time spent on those. I do still feel I refactor half of the time. Then again, I usually never commit the first version even in a “feat” and while doing “tests” I usually refactor more.

But after putting it into numbers, I feel it’s a good distribution. I manage to add a lot of “feats” with only a small amount of “fix” and I do feel I’m moving fast even though almost half of the commits I’m “refactoring”, “testing” and adding “docs”.

It’s as Uncle Bob said, “The only way to go fast is to go well”.

Tell me your counts and what you think about it

If you already do atomic commits and use conventional commits, then let’s compare numbers and perceptions!

If you don’t, no worries, start today, and instead of mindless committing, take time to give a second read of your code as you commit each small piece and catch some errors before anyone else has to point them to you.