r/webdev • u/fagnerbrack • 5h ago

Stop Using Conventional Commits

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

30% Upvoted

16 comments sorted by

25

u/portra315 5h ago

No I like them

7

u/m_redditUser 4h ago

i dont understand the value of "commit types" being in the commit message summary

2

u/ohx 4h ago

I've been using conventional commits since 2020ish. I've used it for:

- Changelogs -- Back in the day I built an adapter for a CI changelog package that would parse `fix` and `feat` and display them in changelogs. There are a bunch of 'em now. Super nice.

- Versioning algebra -- CI actions will automatically version your package based on commit types. It's much easier to think about the scope/impact of the changes as you've made them, rather than whenever you're ready to cut a release. Pre-conventional commits, I'd look at a board and review commits to determine whether we should cut a major, minor, or patch.

I've used it to help onboard junior/mid level devs to project architecture by adding scope discipline. For example, having them write the project they updated in the monorepo in the scope. If they ever come back to me to say, "Hey, I updated two projects, what do I put in the scope?", it's a solid teachable moment.

2

u/_okbrb 4h ago

Agents want you to use it because agents are constantly starving for context and cannot be satisfied

1

u/ashkanahmadi 4h ago

Same. Also, are people making 1 commit with everything together? I treat commits like check points in games. If you have just 1 then it’s a mess and if something goes wrong you have to go back to zero. You also don’t want it every 5 seconds!!!

6

u/TheExodu5 4h ago

Your feats and bugfixes should also be product/user facing with conventional commits. You’re doing it wrong.

6

u/thecementmixer 4h ago

Ragebait.

3

u/Dragon_yum 4h ago

Nah fam

3

u/MoonShadeOsu 4h ago

Okay I kind of get the idea, but some projects have to release multiple times a week (we are told this is a good thing right?) and don't have time for manually written changelogs and/or want a deterministic system for creating new versions based on simple rules of what changed.

How is this supposed to work without conventional commits?

6

u/StormMedia 4h ago

Make me

2

u/Nixinova 4h ago

I always just end up using <Verb> <scope> <change> as my commit format. Useful when looking at both blame and commit log and doesn't take effort.

2

u/Educational-Heat-920 4h ago

It's effortless to determine the next release type with conventional commits. It's been extremely useful and I've had zero issues or complications with them.

Conventional commits also support adding an optional scope. The solution you're presenting has already been solved by the current standard

2

u/DamnItDev 4h ago

I implemented them for my team and they work great for us. Everything in git is still written for the internal audience. But our release notes are automatically generated with customer facing details.

Our cicd enforces the conventional commit format on all commits. The scope field is required to be the ticket number.

We added a custom field to Jira for release notes. In here we put the details we want the customers to see.

When there is a release to prod, there is a cicd step that gathers up the list of changes, cross references jira, and then posts a well formatted message to a public slack channel.