> I work with projects where this is utilized and I'm not sure they are better than nothing. At least you know which commits caused a breaking change compared

> I work with projects where this is utilized and I'm not sure they are better than nothing. At least you know which commits caused a breaking change compared to spelunking the history to figure out how a library broke compatibility and how you need to adapt to it. Breaking changes are honestly one of the main reasons I read changelogs. > The real problem is that commit messages and a changelog serve 2 different purposes and have different audiences. Changelog exists to explain what happened with the product, and commit messages exist to explain what happened with the code. imo a commit summary and the start of the body should explain the the goal, the user facing aspect and then should dig down into the whats and whys of how the changed lines support that goal, using Inverted Pyramid / Bottom-line Up Front writing style. Of course, if the commit has no end-user impact, you signify that with the type (feat/fix/etc vs chore/style/etc) While doing a hand-curated changelog for end-users would be more polished, the summary of a commit message should still be passable.