3 posts tagged with "Implementation Notes"

Why Changelogs Matter​

What Is a Changelog?​

In a software project, a changelog is a running history of feature changes, bug fixes, and improvements. It's usually written for developers and testers. It helps people working on the project understand its history quickly, and can save a lot of time when a rollback is needed.

The main goal is to make changes between versions understandable. A changelog has a few practical benefits:

1. It makes the project more transparent: team members and users can quickly see what changed in each update.
2. It saves the team time by explaining changes in one place, instead of making everyone investigate them again.
3. It helps with issue tracking and rollbacks.

Introduction​

In the previous post, we used Commitizen and Gitmoji to bring some consistency to commit messages. But having a convention doesn't mean everyone will follow it. Plenty of teams still run into this:

“The format looks simple enough, but I keep forgetting the type or getting the syntax wrong.”

Without a check, the convention is just a suggestion. To make sure commit messages consistently follow it, we need an automated check that catches invalid messages.

That's where Commitlint comes in. It validates commit messages against a convention. Whether you're using Conventional Commits or Gitmoji, you can configure checks to keep invalid messages out of the history. Of course, the tool also needs to run at the right moment. With Husky, we can use Git hooks to run Commitlint automatically before a commit is completed, making validation part of everyday development.

In this post, we'll set up:

1. Validation without Gitmoji: Continue the previous setup and check messages with @commitlint/config-conventional.
2. Validation with Gitmoji: Use commitlint-config-gitmoji or commitlint-config-cz to support messages with emoji.
3. Husky integration: Run Commitlint through Git hooks to block commits that don't follow the convention.

Introduction​

I've recently been looking into more structured Git workflows: writing commit messages that follow Conventional Commits, managing version numbers with Semantic Versioning, and so on. I spent quite a bit of time browsing well-known open-source projects on GitHub, learning from their commit histories, PRs, changelogs, and release notes to work out how to build an efficient, consistent workflow.

After some trial and error, I started putting together a few concrete steps I could use in future projects:

1. Use an interactive prompt to help write commit messages that follow the convention.
2. Add a Git hook to check commit messages automatically.
3. Generate a changelog from the structured commit history.

While trying this out, I looked into quite a few tools. One thing caught my eye: lots of open-source projects use emoji in their commit messages. They're easy to scan and, honestly, pretty fun. A little digging led me to a convention called Gitmoji, so I decided to explore how to work it into the same workflow.

There's quite a bit to cover, so I've split these three stages into three posts. Each one goes through the tools, setup, and results both with and without Gitmoji.