Extensive git commit metadata

Commit message format to cover it all

During the past 20 years using version control systems (CVS, SVN, Mercurial, Git) I’ve seen “some” changes — and also committed some myself. While the internet is full of articles describing the “correct” way to write commits, I wanted to describe how I compile my commit messages as of 2026.

There exists a ton of good blog posts, tutorials, and best practices for Git commits. While, for example, Conventional Commits is widely adopted, I personally don’t like it that much: it encourages you to take some precious bits from the subject line for the type of the change, and IMHO that’s wrong.

For the generic formatting of Git commits, one of my go-to articles for over 10 years has been “How to Write a Git Commit Message” by Chris Beams. He compiled this list of “The seven rules of a great Git commit message”:

  1. Separate subject from body with a blank line
  2. Limit the subject line to 50 characters
  3. Capitalize the subject line
  4. Do not end the subject line with a period
  5. Use the imperative mood in the subject line
  6. Wrap the body at 72 characters
  7. Use the body to explain what and why vs. how

I’ve been instructing pretty much every single developer I’ve worked with, to follow these rules since 2015. That produced the most beautiful commits ever. I’m sure everyone agrees. :)

However, one additional thing that I felt was missing for too long was metadata, that helps the readers, CI/CD automation, and probably all the LLM bots in the future. Something easy to understand, easy to parse, and easy to consume.

While fields like Relate(d|s):, Closes:, See:, along with some git-specific Co-authored-by:, Signed-off-by: etc. have been common for over a decade, I felt that something has still been missing.

These document what I’ve been using in the past and how. No research was done to see if others use the same fields, with same or other meanings.

Impact: <major|minor|patch>🔗

To answer questions like

  • How large is the impact of this change?
  • If someone depends on this codebase, do they need to adapt something, even if no releases have been made yet?
  • What should the next released version be from this tree

As I didn’t want to implement any scaling by myself, I just decided to use the definition from Semantic Versioning:

  • MAJOR version when you make incompatible API changes
  • MINOR version when you add functionality in a backward compatible manner
  • PATCH version when you make backward compatible bug fixes

Now I have an easy‑to‑use, well‑defined scale for the impact of a change. It’s usually easy to review whether the commit has been assessed correctly.

Quite often this also helps assess how deep knowledge of the project is required to review a specific change.

Severity: <critical|high|medium|low>🔗

To answer questions like

  • Does this need to get merged now, tomorrow, or maybe next year?

Component: <...>🔗

To answer requirements like

  • allow component-level changelogs
  • automated notifications to other projects we know to depend on specific component

Usually this relates more to monorepos, or codebases that eg. implement multiple microservices.

Scope: <...>🔗

To answer questions like

  • who are the stakeholders that must be kept in the loop

Risk: <high|medium|low>🔗

To answer questions like

  • what level of scrutiny should be used to review or deploy this
  • help release management (eg. postpone releasing high-risk changes)

Migration: <none|db-schema|db-data|...>🔗

To answer questions like

  • how to enable this change, what needs to be done
  • if we know that other components needs roll-outs simultaneously