When you're ready to commit, be sure to write a Good Commit Message™. What's in a Good Commit Message™?
We follow most general engineering best practices from other projects using Git. Some additional guidelines specific to CockroachDB apply.
...
(must) Keep in mind who reads: think of the reviewers & future maintainers, think of the release notes
(must) Use the body to explain what as before/after, and why, not just how
(recommended) Keep the commit title concise but information-rich
(recommended) Use the imperative mood in the subject line, but not in the body
(recommended) Wrap the body at a consistent width under 100 characters
(suggested) Do not end the subject line with a period
Specific to CockroachDB:
(must) Include a release note annotation, in the right position
(recommended) Prefix the subject line with the affected package/area
Table of contents
Table of Contents |
---|
...
Code Block |
---|
docs: summarize changes in title, but be specific More detailed explanatory text, if necessary. The blank line separating the summary from the body is critical; various tools like `log`, `shortlog` and `rebase` can get confused if you run the two together. Wrap the body to a fixed width consistent with the rest of the git history. Explain how the code was, before your change. Explain the problem that this commit is solving. Explain why the problem is important to solve. Explain (briefly) what the new situation looks like. No need to explain the mechanism in detail: the code and comments should explain that already. Are there side effects or other unintuitive consequences of this change? Here's the place to explain them. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here Prefer imperative voice for the subject, and declarative (descriptive) voice for the body and release note. If there are related issues, mention them in the commit message: Resolves: #123 (auto-closes the issue on PR merge and links to the epic in the issue) See also: #456, #789 (cross-references the PR with the issues and epics in the issues) Epic: CRDB-357 (cross-reference the PR with the epic) Release note (general change): The release note should outline what changed, how a user can see what changed, and why it was important / what the impact is. For bug fixes, it should also explain the symptoms of the bug pre-fix and which versions are affected. It should remain concise. A release note can contain multiple paragraphs. This is useful to e.g. provide examples. However it does imply the release note text must appear after the detailed explanation, otherwise the detailed explanation will be considered part of the release note. Release note (general change): if there are multiple release notes, each of them should start with its own "Release note" prefix. |
See further issue and epic reference examples and guidelines.
See further release note examples and guidelines.
...
The first line of the commit message is the commit title.
Tooling around git give gives this line a special role. The title can be at most one line. Do not break it across multiple lines. Separate it from the next paragraph with an empty line, otherwise other tools will become confused.
Prefix your commit subject line with the affected package, if one can easily be chosen. For example, the subject line of a commit mostly affecting the
server
package might read: "server: use net.Pipe instead of TCP HTTP/gRPC connections". Commits which affect many packages as a result of a shared dependency change should probably begin their subjects with the name of the shared dependency. Finally, some commits may need to affect many packages in a way which does not point to a specific package; those commits may begin with "*:
" or "all:
" to indicate their reach.Since the title is prefixed with a package name, don't capitalize the title. In English, the text that follows a colon (
:
) is not capitalized.
Do not end the title with a period. It's a title, not a sentence.
Use the imperative mood for titles. For example, write
docs: clarify user privileges
instead of other moods likedocs: claried user privileges
ordocs: clarifies user privileges
.Not every commit requires both a title and a body. Sometimes a single line is fine, especially when the change is so simple that no further context is necessary. For example:
Code Block docs: fix typo in introduction to user guide
Nothing more need be said; if the reader wonders what the typo was, she can simply take a look at the change itself.
Note however that at least one of the commits in a PR should include a release note annotation in a commit body, if only to state "Release note: none" to declare there are no user-facing changes. See Release notes
Make the commit title short. Other projects have a guideline of trying to keep it around 50 characters. Keeping subject lines short ensures that they are readable in
git log --pretty=oneline
, and forces the author to think for a moment about the most concise way to explain what's going on.Tip: If you’re having a hard time summarizing, you might be committing too many changes at once. Strive for atomic commits.
...