Recently I wrote a lightweight open-source CLI for writing better commits. It helps you follow the Conventional Commit Guideline, while being flexible and configurable.
A good commit history helps others (and the future you) better understand your code and how it came to be that way.
For myself, writing a good commit is like writing good notes. I want to write it in a way that when I look back I can understand why and how I made the decisions I did.
better-commits and the Conventional Commit Guidelines, provide a way to format commits consistently. Doing so can result in some cool side-effects, aside from making your commits easier to read and understand.
Below are a few example commits. These follow the
Conventional Commit Guidelines, and may provide some inspiration for writing better commits.
feat(tools): #3 infer ticket/issue from branch If commit_type.infer_value_from_branch is enabled, will attempt to infer ticket/issue from branch name. Updated documentation with details. Closes: #3
chore!: drop Node 6 from testing matrix BREAKING CHANGE: dropping Node 6 which hits end of life in April
docs: Fix tabbing in defaults section of readme
At my job as a software engineer, I’ve always followed branch and git commit guidelines. However, I’ve ignored maintaining a good commit history in my personal close-sourced projects.
As those projects have grown. I’ve realized that the small increased effort upfront, to write a good commit message, is worth the improved developer experience. — And so I created
better-commits. To be able to quickly and easily follow good practices across all of my projects.
If you enjoy using the better-commits CLI, ⭐️ star it on github, so I feel like the special little snowflake my mother tells me I am.