How I use conventional commits
I like the general idea of conventional commits: tag commits so that you can filter them through your pager. However, especially coming from the context of Rust development, I think conventional commits do not work well as stated.
I don’t really care if commits are feats or breaking (and in early
development, many commits are breaking), so I omit these tags from my
commit messages. Later on, I do care if a line of changes is breaking. I
totally see the value in saying “this is a breaking change” in the
commit description, but when I’m scrolling through all I need are the
versions tagged. In practice breaking releases will typically not
include changes that are really compatible with the previous major
version, because otherwise why wouldn’t you release those changes
separately first? Also, most commits are features, so I’m saving the
extra room in my commit header and not writing feat
.
Instead, I use the absence of a tag to indicate “this is a normal
commit that adds some functionality”. When I want to fix a logical error
up, fixup
. For formatting errors (which shouldn’t ever slip
by since I have a pre-commit hook that runs
cargo fmt --check
among other things), I use the
fmt
tag. Tags should be used sparingly and only for commits
that are “weird” in some way, i.e. commits you ideally never would have
needed to make to begin with.
Of course with Rust, you have to make commits where you just bump up
the version number. Here, a release
tag would be
appropriate.
Tags are things that should be used sparingly for out of the ordinary
commits. The fact of the matter is that most commits add functionality
of some sort to your program, and indicating that with feat
dilutes the value of your actual tags. Conventional commits are a good
set of guidelines to consider for your repository’s Git history, but for
me they hold little value as specifications: they are too intrusive on
the commit history. Especially since I haven’t ever used any
conventional commit tooling and honestly don’t see the point: I just
search for fixup:
or whatever in my Git shortlog.
Overall I think my approach is working out for me, and I find my history a little more readable than a history where everything is tagged. However, there are cases where tagging can present a more concise way to describe the scope of your changes, which is one thing conventional commits do well as is.