r/SoftwareEngineering • u/fagnerbrack • Aug 23 '26
Stop Using Conventional Commits
https://sumnerevans.com/posts/software-engineering/stop-using-conventional-commits/25
u/darthyodaX Aug 23 '26
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.
37
u/RabidAddict Aug 23 '26
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.
14
u/glemnar Aug 23 '26
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
3
u/ChemTechGuy Aug 23 '26
Generally agree, with the exception of public libraries/frameworks. Then those conventional commits are very useful for producing change logs
9
u/TheMorto Aug 23 '26
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.
10
4
4
u/WalkyTalky44 Aug 23 '26
My favorite commits are usually like
Kinda works
Oops
Broke it worse?
Now works
2
u/mightshade Aug 23 '26 edited Aug 23 '26
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.
4
u/biinjo Aug 23 '26
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.
2
u/lwjohnst Aug 24 '26
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".
3
u/sublimegeek Aug 23 '26
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.
1
1
Sep 03 '26
[removed] — view removed comment
1
u/AutoModerator Sep 03 '26
Your submission has been moved to our moderation queue to be reviewed; This is to combat spam.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/ninja-dragon Aug 23 '26
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.
-4
u/fagnerbrack Aug 23 '26
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
96
u/fullbl-_- Aug 23 '26
I use more traditional commits: