Skip to content

Home

Jump to bottom
Jason Chan edited this page Aug 31, 2026 · 6 revisions

Commit message style guide

This is an adaptation of work by Erica von Buelow.

Motivation

It makes going back and reading commits easier. It also allows you to spend less time thinking about what your commit message should be.

From the Deis Commit Style Guide:

It allows us to recognize unimportant commits like formatting.

It provides better information when browsing the git history.

Format of the Commit Message

{type}({scope}): {subject}
<BLANK LINE>
{body}
<BLANK LINE>
{footer}

Rules for Commit Message

Length

  • Keep lines under 80 characters in width.
  • Subject line must not be longer than 60 characters (one line in Github PR description).

Subject - {subject}

Summary of the changes made. The subject line contains a succinct description of the change to the logic. It should complete the sentence:

By implementing this commit, it will ... {subject}

  • Must be present tense
  • Written in the imperative
  • First letter is not capitalized
  • Does not end with a '.'

Allowed Types - {types}

  • feat -> feature
  • fix -> bug fix
  • docs -> documentation
  • style -> formatting, lint stuff
  • refactor -> code restructure without changing external behavior
  • test -> adding missing tests
  • chore -> maintenance
  • init -> initial commit
  • rearrange -> files moved, added, deleted, etc.
  • update -> update code (versions, library compatibility)

Scope - {scope}

Where the change was (i.e. the file, the component, the package). It can be anything specifying place of the commit change e.g. the solver, the input package, the logging package, etc.

Message Body - {body}

(Optional) This gives details about the commit, including:

  • motivation for the change (broken code, new feature, etc)
  • contrast with previous behavior

This is an optional section intended for complex commits that warrant extra explanation.

Some rules for the body:

  • Must be in present tense.
  • Should be imperative.
  • Lines must be less than 80 characters long.

Message Footer - {footer}

(Optional) These are notes that someone should be aware of. Format footer in category blocks. This is an optional section intended for complex commits that warrant extra explanation.

  • TESTING -> how to test the change
  • BREAKING CHANGE -> what is different now that wouldn't work with the old versions, additional things now needed, etc

For example:

TESTING: to test this change, use the boundary conditions file `bc_mfval.inp`

You should see that the solver can now handle multi-wall conditions.

BREAKING CHANGE: the `threefield` solver no longer requires a `mixture` solver
as input when constructed.

Referencing Issues

Reference issues it fixes:

  • closes #14
  • closes #14, #15

Examples

feat(threefield solver): add the Chan, Morse correlation

This implements the latest correlations as published in `Experiments in Fluids` 
article: 10.1007/s00348-003-0697-7

closes #123


docs: create detailed explanations of solver classes

closes #392

Clone this wiki locally