Improving Code Quality — Standardizing Git Commits

In earlier posts I covered commitlint and standard-version for enforcing commit messages and generating clean changelogs. The format still requires manual discipline though. Wouldn’t it be nicer to fill out a form? Thankfully an open-source plugin exists.

commit-template-idea-plugin

Things to note:

1. How to fill each field? Plenty of guides exist, but here’s my shorthand:

   • type — choose carefully. Click into the preset list to read each description. style refers to code style, not CSS.
   • scope — no strict rules; use a business module or a technical area.
   • description — the imperative summary of what changed, e.g., set button background to red.
   • long description — an extended explanation.
   • closed issue — we usually link to tickets; make this mandatory (Jira, GitLab issue, etc.).

   Highlight: the type determines semantic-version bumps. breaking change increments the major version, feat bumps the minor, fix bumps the patch. That explains why dependencies sometimes use ~, ^, or exact versions—semver underpins it all.

   Google’s practice for descriptions is to imagine you’re issuing a command to the computer; write commits in that style.

2. The plugin offers two actions—the first opens the form, the second (highlighted in the screenshot) lists recent commits so you can reuse and tweak them.

3. Commit history is stored per project, not globally.

4. Prefix issue IDs with #; otherwise standard-version can’t link them in the changelog.

Current limitations

1. Projects can define custom change types in .versionrc.json, but the plugin doesn’t read that config.
2. After you submit, the plugin composes a plain-text commit message. There’s no reverse parsing—if you want to edit, tweak the text directly or reopen the form and start over.

An example commit

Angular’s commit style is my personal benchmark. Remember a complete commit also depends on user.name and user.email. I’ve seen colleagues produce three or four different author identities because they work across repos with different Git configs. Git supports conditional includes so you can tailor settings per directory—details here.

Final Thoughts

• Many people downplay commit messages, but they capture history. When reporting iteration progress, a good changelog tells you how many bugs were fixed, which features shipped, and which tickets they map to. Without discipline you’ll be digging manually and still miss items. Automation and conventions save the most time.
• The plugin has gaps, but it’s open source. If you have the motivation, contribute or customize—it’s there for the taking.

Commit → changelog → semver. Clean commits produce trustworthy changelogs, which power semantic versioning.