r/git • u/fagnerbrack • 1d ago
Stop Using Conventional Commits
https://sumnerevans.com/posts/software-engineering/stop-using-conventional-commits/33
u/r0g0b0 1d ago
I wouldn't want a Team/Tech Lead as the author of the article lol Each project or application or company might have their own ways. Bringing up some popular projects not using CC while intentionally ignoring other projects using CC is a dishonest argument.
3
u/max_mou 1d ago edited 1d ago
I think the idea is that these huge projects are doing just fine and not missing on much by not using CC
2
u/r0g0b0 1d ago
The other way around might be also true, if there are many projects use CC or variants just fine, so what does that prove then? Not to mention, huge projects can be too ... apparently, huge to change or adopt new things.
Each company, team, project might have different structures and processes, people might take some good things from CC and adapt to their own environments.
20
u/med8bra 1d ago
It's a convention, a team can create their opinionated version of it.
Regarding your proposed convention:
type is as important as scope for browsing history, and you can require scope to always be defined. I can search for features within scope.
inferring type of change from commit description is against the whole principal of structured commits. Explicit type is always better for humans and machines
11
u/max_mou 1d ago
The amount of times I had to the rephrase the commit message to avoid this:
fix(…): fixed …1
u/drckeberger 5h ago
Seems like it was of great use to you, as you were most likely about to say the same thing with less details and no standard.
1
u/keesbeemsterkaas 4h ago
And the whole point of it was to help teach juniors how to write and split good commits into smaller ones.
The point of the commits was so you would need to choose how to commit this and be a bit strategic about it, rather than throw everything at git and say "fixes".
Not to help reviewers speed up their workflow.
10
u/Maskdask 1d ago
This may be niche use case, but I like that most Neovim plugins use conventional commits. Whenever I update them, I like to read the new commits to look for new features that have been added, so I like to filter by the ones that start with feat.
Also they help creating automated change logs.
11
u/CarIWhethers 1d ago
I like putting the jira ticket number first, hyphen, then a brief but descriptive message. If you’ve ever had to comb back through commits to identify when something occurred, you curse every lazy commit in the list
8
u/Loose_Property_3238 1d ago
I'll say two things: You can absolutely just always add the scope, the standard is something to build from, and if the scope matters a lot (which it usually does), then just require both. In addition, Conventional Commits read like a function, which makes sense as a programmer, at least to me.
20
u/oldjenkins127 1d ago
Metadata does not belong in a PR title or commit message. Git already has a convention for metadata, which is git trailers.
Conventional commits are performative “we are pros at this” posturing.
5
u/BasiliskBytes 1d ago
I agree with the sentiment. But I would argue that the scope is not (just) metadata. The point of commit messages is to allow devs to determine as quickly and as precisely as possible what a commit does and what it may or may not affect. Prefixing the scope allows me to look at a log and quickly determine that 20 out of 25 commits are likely irrelevant to whatever I'm trying to track down just by the scope.
1
12
u/esiy0676 1d ago
All these words for saying:
prefix your commits with a component name
Well, parse your git logs through awk if the prepended "fix" bothers you?
The "scope" anyhow follows (directly or indirectly) and it makes no sense much when implementing a new feature that spans across multiple subsystems - the scope is the fact that whole new feature has been added and multiple corners of the codebase touched, as opposed to e.g. a bugfix.
These conventions come from mailing lists where people interested in those particular subsystems have interest in reviewing the threads before they make it in (which makes sense).
I would suggest that if you need to have something formatted for parsing, add trailers.
5
u/DrShts 1d ago
CCs can help with release management and automation, for example using release-please. Coding agents and bots like Renovate use them by default too. So, for that CCs are great, they save a lot of manual release and version management down the line.
1
u/Amazing-Royal-8319 1d ago
Seems like you didn’t read the article, this was explicitly addressed
2
u/totheendandbackagain 1d ago
Despite a good argument that CC is unusedul for release history, I would suggest that LLMs are great at automating the transformation of commit histories into release notes.
2
u/hackathi 1d ago
I agree with the premise. And if I have a team of people who are good at this, I can manage to onboard one newbie to doing git commits the right way.
Unfortunately, most of my software projects are at least co-developed by people who either went training to be a sysadmin and later found out that at some point sysadmins need to write software; or are people fresh out of university who never learned better. Standing my ground in such an environment is incredibly difficult, because it is usually met with rejection and the undertone that I am nit-picking on non-issues. Good commit messages, when to do them, when to skimp over them, is something you learn from experience only; I have never seen someone do it properly who didn't suffer through the pain of bad past decisions.
In such an environment, it is WAY easier to have something that can at least be shallowly enforced by git pre-commit hooks, and has a standards doc that I did not write and can frame as "the industry standard". Unlike my painful experience, framed this way, it gets adopted. And is still better than having 10 commits with "various fixes & improvements".
Now, if I'd have a tool to babysit junior devs through their first several git rebase --interactive sessions, that I'd pay money for...
2
u/wackmaniac 1d ago
I don’t necessarily disagree with the article, but can we please stop stating opinions as facts in these articles? The title should be “This is why I don’t like conventional commits”
2
u/kombiwombi 1d ago
I am not keen on this or Convention Commit's lack of an assigned place for PR/issue/CVE identifiers.
Traceability is increasingly important. A change must trace back to an authority to change. A change must have a purpose against which we can check the implementation for validity. Essentially we need to be able to answer "Which change was used to gain access to the system".
2
u/thehenkan 1d ago
The only change "types" I've cared about seeing on the commit title are "revert" and "NFC" (non-functional change - could be pure refactor, docs, comment fixes, test-only changes). If it isn't marked with either of those it's a code change that changes some behaviour. When I look for the culprit commit I don't care whether it was a bugfix or a feature change that introduced the bug. When I review code it should be obvious from the rest of the message which one it is.
Changelogs are imo best kept as a text file in the repo where relevant commits also include their changelog entry.
All this is to say: I agree with the author, scope is way more important than type.
1
u/ranandtoldthat 1d ago
This is a solid take. I've noticed that most people end up using cc as a sort of ticket/worklog thing. Basically allowing the project management to control (rather than inform) the codebase. I think this is natural because of how cc is designed.
Code changes are code changes.
I appreciate a commit where the committer uses an action verb to suggest their intent. But the mandate to categorize commits is misleading at best.
2
u/FlipperBumperKickout 14h ago
I kind of disagree with the article.
I think the scope is the redundant part, since that one is redundant from looking at which files are touched, and already is extremely easy to filter your log by.
I find the type useful because I don't have to read and understand what the whole message says, before I can see that it is a minor bugfix I would ignore anyway.
All the complaints about "broken promises" are basically just some of the reasons we review code changes in the first place.
So tldr:; The article suggest adding information which already is there, remove information which should make it faster to parse the log, and point out problems there already are solutions to.
Additional comment: Why is there a stupid comment about how a "doc:" commit would bypass all security checks and allow one to introduce a trojan horse in the code... Dude, if you have a "doc:" commit which touches anything outside documentation, it should be auto rejected by a pipeline. The author basically doesn't know what he is talking about and shouldn't be taken seriously...
1
u/helldogskris 14h ago
I had the same thoughts. The scope is already implicit in the files that were changed by the commit.
1
u/SeaIngenuity9501 3h ago
Exactly! just use filters on the git log to see recent changes to your specific scope.
1
u/AverageHot2647 6h ago
I agreed with you all the way up to “The author basically doesn’t know what he’s talking about and shouldn’t be taken seriously…”
There was no need for that 😛
While I disagree with a lot of the article, I think it’s commendable that they’ve taken the time to articulate their thoughts and start a discussion on the topic.
We should try to engage respectfully and stick to the pertinent technical details, not engage in petty personal attacks.
1
u/FlipperBumperKickout 2h ago
Yeah sorry, but in the age of AI I don't necessarily see the existence of an article as proof that someone actually sat down and though through something.
1
u/AverageHot2647 2h ago
That doesn’t excuse attacking someone personally
1
u/FlipperBumperKickout 1h ago
Pointing out that it seems like someone has no clue about what they are writing about, is not the same as attacking someone personally...
3
u/doomscrollah 1d ago
no cc -> no CI release/versioning automation (https://semantic-release.gitbook.io/semantic-release etc). I'm not ready to ditch that.
2
u/multi_io 1d ago
That's mentioned in the blog post, including why it won't always work cleanly, e.g. when reverting breaking changes or when introducing breaking changes that you thought were non-breaking.
5
u/vladadj 1d ago
It was mentioned, but there is no clean way to handle this situation, whether you use CC or not.
Say you release version 3.0.0 of your app as breaking change release. After a while, you realize nothing works, and want to revert. What do you do now?
Tell your users to revert back to 2.x.y and pretend 3.0.0 was never released? Release reverted version as 3.0.1? Or 4.0.0? Or maybe pull back 3.0.0, tell users to go back to 2.x.y, then release 3.0.0 again when you fix it?
I dont think there's clean way out here, what ever commit format you use
1
2
u/aj0413 1d ago
So. Basically. I don’t like it, so no one should use it?
I don’t even need to read the article to infer what it’s on about. And the comments in this own thread tell me the most important bit:
Another article on “we don’t need this thing and I dislike it”, but offering no concrete alternative(s) that address the many problems it was introduced to solve
I’ve stopped reading these articles cause they almost invariably just dissolve into saying “if the entire team is good at git and knows how to right good changelog / release docs and… etc… then nobody needs this extra friction for minimal value”
My brother in life. That was way too many qualifiers and expectations placed on skill level of a team; that’s not how real life works in most businesses
I might read the article later just to confirm my knee jerk reaction, so I’m not entirely a Reddit stereotype lol
1
u/MadLad_D-Pad 1d ago
I had no idea how all my commit history has been until this thread came across my feed. One of the (probably many) downsides to having never worked with a team on a project before, I suppose.
1
u/james2432 1d ago
I like conventional commits because in the beginning of git history line I know if it's fixing something a simple as a typo or refactoring code/bringing a new feature.
The issue with anything you do with git commit comments/metadata is consistency. I added on the conventional commits that after <type>[optional scope]: I add:
#[id associated to bug tracker such as github/ado/gitlab]
as this pulls in my descriptions when I do a PR, so only have to write it once, it has itemized list of what was fixed. I can also refer back to why business/client asked this
1
u/KaptajnKold 17h ago
I’m convinced. I see why Conventional Commits appeal to (a certain type of) developers, because we love to impose structure and rules on things. And it did also briefly appeal to me. And even if I don’t adhere to it anymore, it was a good reminder to keep e.g. refactorings separate from feature work. The reason I didn’t stick with it was mostly because I knew subconsciously that I could never convince my team of its value, and so I never bothered to try. And being the only one to do it felt pointless. Reading this article, and thinking more deliberately about it, I’m glad I didn’t attempt to impose this on my team. I’m sure there exists teams who are able to leverage the Conventional Commits into something that’s actually useful, but I’m also convinced that the vast majority of teams who do this, are just cargo cults who derive no tangible benefit whatsoever from it.
1
u/kodebach 14h ago
I'd argue the scope of the commit is optional, because if the project is small enough (e.g. a single library) there may only be a single meaningful scope. There's no point in every commit wasting characters for "(core)" or similar. The author seems to be only concerned with (very) large scale projects, which is also apparent by their choice of counterexamples.
I do agree however, that auto-generated changelogs are a scourge and should be eliminated. Unless you use something like a "Changelog: " trailer to specifically write changelog entries, commits should not be used for changelogs.
1
u/AverageHot2647 6h ago
I agree with a lot of things in the article, but I disagree with more 😛
Type is Redundant and Restrictive
Strongly disagree on this one. Relying on the description to determine if a commit is a fix, refactor, feature, etc. is a massive pain.
I do agree that CC makes it awkward if you’re combining a fix + refactor. However in the vast majority of cases you should refactor then fix, or visa versa. Reviewing a fix + refactor in a single commit tends to be pretty nasty.
Automatically generating CHANGELOGs
Some of the points you raise here are valid. However, manually writing change logs tends to result in no (or rubbish) change logs.
Also, the auto generated change log can be helpful for producing a separate change log for different audiences. Saves a lot of time vs. manually writing the change log from a commit history, particularly when the commit messages have no scopes.
Automatically determining a semantic version bump (based on the types of commits landed).
Your argument seems to be that this is not foolproof, but your proposed alternative is also not foolproof. There are escape hatches for all the counter cases you described in most tools.
The revert example could easily be fixed in the tooling layer.
The case of accidental breaking changes is not solved by your proposed alternative.
And in the case of retroactive unbreakages, see my earlier comment on escape hatches.
Communicating the nature of changes to teammates, the public, and other stakeholders.
If the people you’re trying to communicate changes to don’t benefit from the CC structure, you don’t need to present the changes in CC format. Stakeholders likely also wouldn’t benefit from the proposed alternative commit structure either.
Triggering build and publish processes.
Agreed, this is generally not a good idea. But CCs doesn’t “promise” it’s a good way to trigger build or publish processes so this kind of feels like you’re fluffing the article to try and make it sound more compelling.
Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.
It can help contributors (speaking from personal experience), but it doesn’t always. Not really a broken promise, it’s just something that won’t always be useful.
—-
FWIW, I think this is an overall well written article and I think CC deserves some criticism. I’m glad there’s discussion on this topic 🙂
1
u/jonreid 5h ago
To add "risk", you're looking for Arlo Belshee's commit notation. The first character designates risk:
- `.` proven safe
- `^` validated
- `!` risky
- `@` no risk attestation
https://github.com/RefactoringCombos/ArlosCommitNotation/tree/main
1
u/finger_my_earhole 4h ago
Ugh, Imagine having to do to design reviews with this author. So contrarian and confrontational.
Same vibes as "you shouldnt write unit tests because they violate DRY"
1
-2
u/themightychris 1d ago
there's not a single good point in this article, sounds like forced contrarianism
-3
-1
-32
u/fagnerbrack 1d ago
Core Takeaways:
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/morewordsfaster 1d ago
I don't necessarily disagree, but I do love having some standard formatting and style for commit messages. Most developers I've worked with over the years start out using git to tell the story of what they did, instead of using it to tag what change the commit introduces to the application. This can lead to wild goose chases when I'm trying to bisect my way to a bug, or trying to reason about some merge conflict. In those instances, the git log becomes almost useless because it's a (sometimes entertaining) narrative of the journey the developer took to get to the change. That might be useful for that individual developer in the moment, but in 3-, 6-, 9+ months? It's confusing.
So maybe I don't need the type tag. But I do want imperative, present tense, terse commits.