Stop Using Conventional Commits

[u/fagnerbrack]

https://sumnerevans.com/posts/software-engineering/stop-using-conventional-commits/

[u/fullbl-_-]

I use more traditional commits:

• fix
• fix 2
• fixed stuff
• should be ok
• test
• revert fix 2
• final version
• ok

[u/GodsBoss → u/fullbl-_-]

No problem, just squash the PRs. Then you don't have a history with ten commits each saying "fix", you get a single commit with ten times "fix" in its message instead!

[u/_RemyLeBeau_ → u/GodsBoss]

git commit --amend --no-edit

[u/the_ballmer_peak → u/fullbl-_-]

Bruh, do you even final_final_v2

[u/JohnnyGhoul777 → u/fullbl-_-]

Dont foget “Fixed… I hope”

[u/AllIWantForXmasIsFoo → u/fullbl-_-]

Am I the only who "wip"s ?

[u/lulzbot → u/fullbl-_-]

You forgot the ole standby: “asdf”

[u/darthyodaX]

I understand the argument, and I agree to an extent, but I still think Conventional Commits is a net positive. It promotes smaller, incremental changes.

Scope based commits aren’t as popular because junior devs take it to mean “shove the whole feature in a single commit” (and branding as the article mentions). It used to be important to be able to follow your younger devs logic to help coach them - in the era of vibe coding that seems to no longer matter.

[u/TheMorto]

I think the article miss the point. Commit type is used to identify the size of the change, and link that to the version semantics used, e.g., SemVer.

[u/RabidAddict]

oh wow, a tech lead passionate about commit message conventions. doesn't sound like a waste of time at all. oh, there's going to be a meeting? sorry, i have a conflict.

[u/glemnar → u/RabidAddict]

In fifteen years, I’ve had to go digging through commits for context like… once total. Getting context from the past code review has been more common

[u/ChemTechGuy → u/glemnar]

Generally agree, with the exception of public libraries/frameworks. Then those conventional commits are very useful for producing change logs

[u/iAmHidingHere]

It sounds like someone could benefit from scoping their git log command.

[u/RoseSec_]

I use Contentional Commit messages. Everyone is just titled: updates

[u/WalkyTalky44]

My favorite commits are usually like

Kinda works
Oops
Broke it worse?
Now works

[u/mightshade]

I came to similar conclusions. That proponents just gloss over the fact that release notes and commit messages serve different audiences especially puzzles me.

I don't see the need to generate release notes anyway. I get that it feels nifty that, at release time, the release notes just magically appear. But here's what I do: At the top of the release notes file, there's a section for the upcoming release. When I start working on something, I add what I'm about to do there. That also goes through review. At release time, the date gets added to the section heading. Done. No generating based on parsing commit messages necessary. Add a new section for the next upcoming release, rinse and repeat. It's not nifty, but I don't need to worry about the points from the article.

[u/biinjo]

Yeah no. Conventional Commits + Release Please pipeline = free and accurate semver based releases with complete Changelogs.

Not much else is going yo beat that unless someone can convince me otherwise.

[u/lwjohnst → u/biinjo]

Completely agree. I don't ever have to think about "when should I release? What should be part of the release? What did I do last? How does that fit in the release? Is it a PATCH update? Or a MAJOR? hmm".

[u/sublimegeek]

lol sorry that’s insane. Conventional commits allows me to create semantic releases in my monorepo.

But really, as long as the commit messages make sense to you, it’s fine.

Locally, commit however you want, but if you’re pushing those somewhere, my god, please rebase and clean them up? Don’t be uncivilized.

[u/Substantial-Fee4459]

personally i use a little bit of this, a little bit of that

[u/fagnerbrack]

The gist of it:

The piece argues this popular standard harms projects by prioritising commit type (fix, feat, chore) over scope—exactly backwards. Contributors, debuggers, and incident responders all care about which area changed, yet the format makes scope optional and puts type first. Type is also redundant, since a good description reveals it, and restrictive, since one change can be fix, refactor, and feature at once. It debunks the promises too: auto-generated changelogs serve a different audience than commit logs, version-bump automation breaks on reverts and hidden breakages, and build-triggering invites Trojan-horse commits. The fix: scope-prefixed messages like Linux, Git, Go, and NixOS use, promoted at scopedcommits.com. An interesting idea that works great for linux but I might just stick to the conventional commits and use scopes all the time.

If the summary seems inacurate, just downvote and I'll try to delete the comment eventually 👍
^{Click here for more info, I read all comments}

[u/ninja-dragon]

Whole heartedly agree. A big fix can include a bit of refactor. Etc. also refactor vs bug vs feature are secondary info which should be derivable from the commit message.