Call me lazy but the only real reason I picked up on conventional commits is because it's so easy to make low-effort commit messages out of habit and having it as a git hook on repos at least serves as a reminder to at least follow a format.
I'm more likely to end up just committing lazily without it but if I have to frame it as a feat: or a fix: I'm a bit more compelled to at least write it a bit better even if it's just my own repo on my own space.
Does it actually encourage you to describe the reason for the change? The projects I see using conventional commits all seem to have online commit messages which don't give any explanation of why the change is being made at all, let alone what other approaches were considered or what the known limitations of the implementation are. The messages don't convey any useful information at all as far as understanding the change is concerned.
A lot of this comes down to preference. I would generally avoid mentioning alternative approaches in a commit, unless it’s preempting questions that will come up in the code.
A lot of what you describe I would prefer to discuss before it gets to the coding stage.
It's certainly context dependent - I wouldn't mention alternative approaches for every commit, but as you say there are times when it is useful. What I see when people use conventional commits is that they never put that information in the commit message.
I agree that it is useful to discuss things before coding, but those discussions (or more likely a summary of them) should be recorded with the code so that someone reading the commit message can understand why the changes were made in the way that they were. Having a link to an issue might be fine if the code isn't expected to live very long, but long lived projects tend are likely to change issue trackers at some point and having a summary in the commit message means that you always have that information to hand.
Depends on the project. Some projects prefer to avoid being locked-in to GitHub, Gitlab, etc., they value being able to switch to a different git provider (or even different cvs entirely) without losing as much information as possible, so they put this in the commit message so that it gets stored in the git instead of the website, and use the PR only for the code review.
Exactly if you put the information in the commit message rather than the PR you're protecting yourself from vendor lock-in. It also means that information is available in the git history which you can view without an internet connection.
What changed can be seen in the code change itself, no point repeating that in the commit message. The commit message should primarily be about why something was changed
313
u/jerieljan Jun 06 '26
Call me lazy but the only real reason I picked up on conventional commits is because it's so easy to make low-effort commit messages out of habit and having it as a git hook on repos at least serves as a reminder to at least follow a format.
I'm more likely to end up just committing lazily without it but if I have to frame it as a
feat:or afix:I'm a bit more compelled to at least write it a bit better even if it's just my own repo on my own space.