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
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:
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- 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