Skip to main content
Follow these best practices when writing commit messages for the Dart SDK to maintain consistency and clarity across the project.

​
Commit Message Structure

1

First line: Capitalized, short summary

The first line should be a capitalized, short (50 chars or less) summary.Include the component name for which the change is being made:
  • [Analyzer] short (50 chars or less) summary
  • [dart2js] short (50 chars or less) summary
  • [CFE] short (50 chars or less) summary
  • [CoreLib] short (50 chars or less) summary
  • [ddc] short (50 chars or less) summary
  • [VM - Runtime] short (50 chars or less) summary
  • [VM - GC] short (50 chars or less) summary
2

Always add a blank line

Always add a blank line before more information. Many git tools assume this layout and rely on it for proper formatting.
3

Detailed explanation (if necessary)

Add more detailed explanatory text if necessary. Wrap it to about 72 characters or so.This section should provide context about:
  • Why the change is needed
  • What problem it solves
  • Any important implementation details
4

Link to GitHub issues properly

When linking to an associated GitHub Issue:DO:
  • Use the full GitHub URL to the issue (ensures the issue is clickable in Gerrit)
  • Use GitHub notation to auto-close bugs on commit: 
    Closes https://github.com/dart-lang/sdk/issues/25595
DON’T:
  • Put Issue 234 in the title
  • Use the old BUG= format: 
    BUG=https://github.com/dart-lang/sdk/issues/25595
If you don’t want to delete the BUG= boilerplate, at least add a space after the = to ensure the issue link is clickable in Gerrit.
5

Use present tense

Write your commit message in the present tense: “Fix bug” not “Fixed bug.”This convention matches up with commit messages generated by commands like git merge and git revert.

​
Complete Example

Here’s a complete example following all the guidelines: 
[VM - GC] Summarize changes in 50 chars or less

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.

Closes https://github.com/dart-lang/sdk/issues/1

Further paragraphs come after blank lines.

- Bullet points are okay, too

- Use a hyphen or asterisk, followed by a single space.

- Use a hanging indent for 
  longer lines

​
Component Prefixes

Use these component prefixes to help identify which part of the SDK your change affects:

[Analyzer]

Changes to the Dart analyzer

[dart2js]

Changes to the dart2js compiler

[CFE]

Changes to the Common Front End

[CoreLib]

Changes to core libraries

[ddc]

Changes to the Dart Dev Compiler

[VM - Runtime]

Changes to VM runtime

[VM - GC]

Changes to VM garbage collection

​
Quick Checklist

Before committing, verify your commit message:
  • First line is 50 characters or less
  • Component prefix is included (e.g., [Analyzer])
  • Blank line after the first line
  • Detailed description wrapped at 72 characters
  • GitHub issue linked with full URL
  • Uses Closes https://... for auto-closing issues
  • Written in present tense
  • Summary focuses on what and why, not how

​
Common Mistakes to Avoid

Don’t put issue numbers in the title:
❌ Issue 234: Fix analyzer bug
Do use component prefix and descriptive summary:
✓ [Analyzer] Fix null safety inference bug
Don’t use past tense:
❌ [CoreLib] Fixed memory leak in List
Do use present tense:
✓ [CoreLib] Fix memory leak in List
Don’t use short issue references:
❌ Fixes #25595
Do use full GitHub URLs:
✓ Closes https://github.com/dart-lang/sdk/issues/25595

​
Additional Resources

Build docs developers (and LLMs) love

Get started for freeTalk to us