3 ms·
I use git-cliff for my personal projects. If you follow conventional commits and squash merges, you get a clear, user-friendly changelog—it's easy to "skip" com
by welpo 2y ago
I use git-cliff for my personal projects. If you follow conventional commits and squash merges, you get a clear, user-friendly changelog—it's easy to "skip" commits that don't affect the end user.
I wrote a tool to validate commits, which helps ensure both the git history and changelog look clean: https://github.com/welpo/git-sumi https://github.com/welpo/git-sumi
- pseudalopex 2y agoRepeated items, items irrelevant to users, details irrelevant to users in each item, and poor organization in each section make the git-sumi release notes unclear and user unfriendly.
- welpo 2y agoYou're right; there is a lot of noise in the git-sumi changelog. As it matures (and I tinker less with it), it should get better. Here's a better example on a more mature project: https://github.com/welpo/tabi/blob/main/CHANGELOG.md https://github.com/welpo/tabi/blob/main/CHANGELOG.md
- pseudalopex 2y agoThe tabi release notes have items irrelevant to users, details irrelevant to users in each item, and poor organization in each section.
- doix 2y agoYou don't _need_ to squash, if you don't want too. You can merge and use conventional commits for the merges. Then git log --first-parent gives you the change log whilst also not not forcing you to squash.