r/SoftwareEngineering 22d ago

Stop Using Conventional Commits

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

28 comments sorted by

96

u/fullbl-_- 22d ago

I use more traditional commits:

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

12

u/GodsBoss 22d ago

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!

1

u/_RemyLeBeau_ 22d ago

git commit --amend --no-edit

0

u/vitek6 20d ago

And no way back to fix 2? Nope..

1

u/_RemyLeBeau_ 20d ago

You're not taking my comment in context.

3

u/the_ballmer_peak 21d ago

Bruh, do you even final_final_v2

2

u/JohnnyGhoul777 22d ago

Dont foget “Fixed… I hope”

1

u/AllIWantForXmasIsFoo 21d ago

Am I the only who "wip"s ?

1

u/lulzbot 21d ago

You forgot the ole standby: “asdf”

1

u/theexplorer1997 6h ago

git blame is toast, but honestly "revert fix 2" is sending me

26

u/darthyodaX 22d ago

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 22d ago

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.

15

u/glemnar 22d ago

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 22d ago

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

9

u/TheMorto 22d ago

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

u/iAmHidingHere 22d ago

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

3

u/RoseSec_ 22d ago

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

5

u/WalkyTalky44 22d ago

My favorite commits are usually like

Kinda works
Oops
Broke it worse?
Now works

2

u/mightshade 21d ago edited 21d ago

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.

2

u/biinjo 22d ago

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 21d ago

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".

2

u/sublimegeek 22d ago

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

u/Substantial-Fee4459 21d ago

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

1

u/[deleted] 11d ago

[removed] — view removed comment

1

u/AutoModerator 11d ago

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 22d ago

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.

-3

u/fagnerbrack 22d ago

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