I think some structure in commit messages is helpful, but not to the point where it gets in the way of effectively reflecting what the commit contains, why it was done, and any comments for future reference, e.g. potential regressions.
Conventional Commits encourages focus on the wrong things
21–30 of 294 posts
Re: Conventional Commits encourages focus on the wrong things
#22My main complaint with conventional commits always was that they don't include an issue number in the commit title. It's not even mentioned in their standards as optional or something. To me this is almost the most important information in a commit message. I don't know how often in the last 15 years I was cross checking the issue description referenced by some old commit to get the full context of a change. I also f…
It isn't a standard, it is a convention. You can set a standard within your team to include the ticket id in the commit message.
Re: Conventional Commits encourages focus on the wrong things
#23My main complaint with conventional commits always was that they don't include an issue number in the commit title. It's not even mentioned in their standards as optional or something. To me this is almost the most important information in a commit message. I don't know how often in the last 15 years I was cross checking the issue description referenced by some old commit to get the full context of a change. I also f…
[deleted]
Re: Conventional Commits encourages focus on the wrong things
#24Odd. The main reason to use this style of commit message is for CI/CD automation.
EDIT: I didn't see this covered in the article on my first pass. It is covered though. My apologies.
The type of the commit informs the automated workflows how to handle the commit. This is why it comes first.
For example, if you're performing CD, if you only commit a bunch of `fix: ` then only your semantic versioning patch version number is incremented. If you commit a `feat: ` then it's a minor version is bump. `feat! ` is a major version bump.
Even if you're not using CD for releases, semantic commit messages are sometimes used to automate change log generation. Granted, your change logs should not typically include the Git commit messages themselves — those are developer facing, not user facing.
Re: Conventional Commits encourages focus on the wrong things
#25My main complaint with conventional commits always was that they don't include an issue number in the commit title. It's not even mentioned in their standards as optional or something. To me this is almost the most important information in a commit message. I don't know how often in the last 15 years I was cross checking the issue description referenced by some old commit to get the full context of a change. I also f…
yeah this is the actual key. an actually useful title and a stable link to the discussion around the change.
conventional commits are pleasing, but questionable actual utility. the code speaks for itself. the actually useful information is a well chosen title and the context for the change.
Re: Conventional Commits encourages focus on the wrong things
#26The thing conventional commits are really helpful for is continuous delivery. Every merge to main can be automatically tagged with semver and shipped because the thought that goes into tagging and versioning has already been done by the developers when they wrote the commit message. I fully recognise that it doesn't make sense for huge projects like the Linux kernel to do this. But for 99% of projects conventional co…
I do this on my OSS projects to automate semver bumps and it's amazing! At work, I also enforce "tags" (not git tags, just strings in the PR title) based on who cares about the change and then generate changelogs for the respective teams based on those "tags".
Re: Conventional Commits encourages focus on the wrong things
#27As a solo developer, I rarely struggle to remember what changed yesterday. I often struggle to remember why I made a decision six months ago. Conventional commits are most valuable to me as historical context rather than as a release-management tool. The larger the project becomes, the more useful that context gets.
This sounds like what regular commit messages do. How are conventional commits specifically helpful?
Conventional commits (especially with git emojis) show at a glance the blast radius of the change (eg whether it breaks the product itself or just some internal dev tools). Emojis help immensely when looking at dozens of commits at a time.
Re: Conventional Commits encourages focus on the wrong things
#28Odd. The main reason to use this style of commit message is for CI/CD automation. EDIT: I didn't see this covered in the article on my first pass. It is covered though. My apologies. The type of the commit informs the automated workflows how to handle the commit. This is why it comes first. For example, if you're performing CD, if you only commit a bunch of `fix: ` then only your semantic versioning patch version num…
No no. You see we need to get rid of conventional commits so AI can make commits easier.
Re: Conventional Commits encourages focus on the wrong things
#29I totally agree.
If one needs to put metadata in commits, usually better to just put it in a Git trailer.
https://git-scm.com/docs/git-interpret-trailers
`Co-authored-by: Alice` is a common one, but you can have anything in there.
Re: Conventional Commits encourages focus on the wrong things
#30There’s a much less awkward way to keep a change log:
Keep a change log.