A commit message should be composed with care and discipline. It is a chance to help your future self or other people to understand why you did what you did. And commit messages like fixed things, implement feature, or kjögren bto 3 25 will not help anyone—ever. Good commit messages have a similar style, are concise, and explain what was done and why.

Chris Beams has a great post about commit messages on his blog which defines the following seven rules:

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

In another great post by Tim Pope a great template for commit messages is given which I adapted.

Capitalized, short (50 chars or less) summary

More detailed explanatory text, if necessary.  Wrap it to about 72
characters or so.  In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body.  The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.

Further paragraphs come after blank lines.

- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, followed by a
  single space, but conventions vary here

Related to: #12345

If you have a monorepo which includes multiple applications you should prefix the subject line with the name of the application that is affected by the commit. For such subject lines the maximum length is increased by the length of the prefix. Some example subject lines:

[backend] Add service for something

[frontend] Add breadcrumbs

[worker] Fix scheduling of emails