Git-cliff – Generate changelog from the Git history

1. ratatui

   1 58 9,517 9.7 Rust

   Discontinued Rust library that's all about cooking up terminal user interfaces (TUIs) 👨‍🍳🐀 [Moved to: https://github.com/ratatui/ratatui] (by ratatui-org)

   

   > It looks like the commits are lightly processed (scanning “type”, removing it, moving it to the correct section/heading), put in bullet points, adding a hyperlink to the commit hash, using section breaks for something (maybe per PR or something).

   Yeah pretty much. The config is at https://github.com/ratatui-org/ratatui/blob/main/cliff.toml

   > It looks nice. And verbose. Like a lot of refactoring bullet points.

   Most of the bullet points are single features / changes to the library that are delivered to the users of the library.

   > The “squashed” commits don’t look good but that’s the fault of squash commits (as usual).

   Can you give an example of this? Everything you're seeing in the changelog is a commit that has been pushed to the repo with a title message and a manually crafted body - we generally avoid letting the body be the github squash commit PR message junk.

   > In the end this is a very light shim on top of git log. (Light in terms of data, not light in terms of the discipline and visual overhead the so-called Conventional Commits standard demands).

   Yeah, and that's generally useful from the perspective that it's available online, searchable in a single doc (which makes it easy to answer questions like "when was blah implemented"

   There's probably a bunch of things that would make this even better, but there's diminishing returns on the effort involved in doing so.

2. SurveyJS

   surveyjs.io featured

   JavaScript Form Builder with No-Code UI & Built-In JSON Schema Editor. Add the SurveyJS white-label form builder to your JavaScript app (React/Angular/Vue3). Build complex JSON forms without coding. Fully customizable, works with any backend, perfect for data-heavy apps. Learn more.

   

3. keep-a-changelog

   2 11 6,274 6.0 Haml

   If you build software, keep a changelog.

   

   I am definitely more in the changelog-as-a-file camp. From https://keepachangelog.com/:

   > Using commit log diffs as changelogs is a bad idea: they're full of noise. Things like merge commits, commits with obscure titles, documentation changes, etc.

   > The purpose of a commit is to document a step in the evolution of the source code. Some projects clean up commits, some don't.

   > The purpose of a changelog entry is to document the noteworthy difference, often across multiple commits, to communicate them clearly to end users.

4. semantic-release

   3 89 21,903 9.5 JavaScript

   :package::rocket: Fully automated version management and package publishing

   

   I'm also pretty unclear on what the "bump" command does. Does this create a git tag? Make a new commit? Have hooks to update version constants in the source? Seems liek the answer to all of these is "no", and so I'm not really sure how useful it is.

   I'm also aware of related tool in this space: semantic-release <https://github.com/semantic-release/semantic-release>. I haven't used it in my repositories, but it seems like a more comprehensive verison of git-cliff.

5. conventional-pre-commit

   4 2 413 7.3 Python

   A pre-commit hook that checks commit messages for Conventional Commits formatting

   

   You can use conventional pre-commit[0] to validate that commit messages follow the convention and use only the types that the team agreed upon.

   This still requires discipline to choose the "right" type and scope.

   [0] -- https://github.com/compilerla/conventional-pre-commit

6. git-sumi

   5 1 22 9.3 Rust

   The non-opinionated Rust-based commit message linter.

   

   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

7. epage

   6 2 - -

   Discontinued [GET https://api.github.com/repos/epage/epage: 404 - Not Found // See: https://docs.github.com/rest/repos/repos#get-a-repository]

   For me, I find this approach better than nothing and would not shame or discourage someone from using it over hand written.

   That said, I am wanting a Github action based release workflow and want it to scale to manual edits of changelogs, so this is insufficient for me. Instead, I've been taking notes on changelog fragments as I hope they can offer the best of both worlds, see https://github.com/epage/epage.github.io/issues/23

8. tabi

   7 2 182 9.3 JavaScript

   An accessible Zola theme with search, multi-language support, optional JavaScript, a perfect Lighthouse score, and comprehensive documentation. Crafted for personal websites and blogs.

   

   You'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

9. InfluxDB

   www.influxdata.com featured

   InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.

   

10. husky

    8 150 33,489 8.1 JavaScript

    Git hooks made easy 🐶 woof!

    

    I don't know where you're getting this but there are in fact many tools for local commit hooks https://typicode.github.io/husky/

Suggest a related project