Table of Contents

Git Commit Messages

This document provides guidelines on how to write a well-formed commit message when developing for MantisBT.


See Details and explanations section below for further information.

  1. Summary
    • Maximum length 72 characters, try to stay under 50 if possible.
    • Describe the change in the patch, not the bug or effects/benefits.
    • No trailing period.
  2. Description
    • Optional if the Summary is self explanatory
    • Always add a blank line between summary and description
    • Wrap lines at 72 characters
    • Background information and details on the change (i.e why, how, references, etc)
    • Description must be understandable for everyone
  3. Bug reference
    • Optional, but most commits should reference an issue in the bugtracker, formatted for use by the Source Integration plugin
      e.g. Fixes #1234, Issues #123, #456
  4. Sign-off if the commit's author is not a MantisBT core developer

Commit contents

This is somewhat out of scope of this document, but nevertheless related information, so here goes.

Remember that each commit should cover only one single logical/functional change.


Details and Explanations

A good commit message should basically answer three questions about a patch:

  1. Why is it necessary?
    It may fix a bug, it may add a feature, it may improve performance, reliabilty, stability, or just be a change for the sake of correctness.
  2. How does it address the issue?
    For short obvious patches this part can be omitted, but it should be a high level description of what the approach was.
  3. What effects does the patch have?
    (In addition to the obvious ones, this may include benchmarks, side effects, etc.)


The Summary line is used all over Git, oftentimes in truncated form if it is too long. It should be kept under 50 characters if possible, but not be more than 72 characters long.

Using a long Summary may make it more difficult to understand what the commit is about when using one of the below (and other) commands.

Examples of where it ends up:

Remember to always add a blank line between Summary and Description.

Why 72 chars

Configuring editor for word wrap



The commit's Description should be as long as necessary, and in terms of contents, must



When committing changes submitted by non-core team members, the commit must be signed off by the committer in the case of individual commits (use git commit -s). This is not necessary when merging several commits as a feature branch, as the merge commit itself will serve as sign off.


Based on model message in Tim Pope's blog post (see references).

Capitalized, short summary (50 chars or less)

More detailed explanatory text, if necessary, wrapped to 72 characters.
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.

Write your commit message in the imperative: "Fix bug" and not "Fixed
bug" or "Fixes bug." This convention matches up with commit messages
generated by commands like git merge and git revert.

You can have the Source Integration plugin automatically reference issues #1234, #1235 (the changeset will be linked to the
issues when pushed).

Further paragraphs come after blank lines.

- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet
- Add blank lines between bullets if needed for clarity
- Use a hanging indent when a bullet's text is too long to fit on a
  single line

Fixes #5678 (commit will be linked to the issue, which will be marked as
resolved when pushing the commit).

Signed-off-by: Core Developer <>


These guidelines were mainly inspired by

To do

Grangeway suggested to implement a commit hook to perform validation on commit message, e.g.