Commit Message rules for TYPO3 CMS

Git and related tools work best when following a certain guideline for commit messages. A deeper introduction on git revision log conventions is helpful to understand the scope.

A commit message might look like this:

[BUGFIX] Short summary of changes introduced by this patch

Most importantly, describe what is changed with the commit
and not what is has not been working
(that is part of the bug report already).

More detailed explanatory text, if necessary. Wrap it to 74 characters.
The first line is treated as the subject of the commit message and
the rest of the text as the body.  The blank line separating the
subject from the body is critical (unless you omit the body entirely);
tools like git rebase can get confused if you run the two together.

Write your commit message in the '''imperative present tense'''
("Fix bug", not "Fixed bug"). This convention matches up with generated
commit messages by commands like git merge and git revert.

Help others to understand what you did (Motivation for the change?
Whats the difference to the previous version?), but keep it simple.

Problem description as well as testing and/or reproduction instructions
shall be part of the Forge ticket referenced below.
The commit message solely describes '''what is changed'''.

* Bullet points are okay, too
* An asterisk is used for the bullet, it can be preceded by a single
  space. This format is rendered correctly by Forge (redmine)
* Use a hanging indent

Change-Id: I<some string generated by the git commit-msg hook>
Resolves: #12346
Related: #12340
Releases: master, 6.2

As the commit message is kept in the history of the Git repository, please consider writing a proper message!

Topic description (first line)

  • Prefix the line with a tag: [BUGFIX], [FEATURE], [TASK] or [CLEANUP].
  • Keep the whole line below 52 characters if possible, but below 80 in any case

Possible tags are:

A new feature (also small additions). Most likely it will be an added feature, but it could also be removed. Features may exclusively be targeted for the "master" branch of TYPO3 CMS, because no new features are allowed in older branches. Exceptions to this have to be discussed on a case-to-case basis with the designated release managers. Features have to be documented according to TYPO3 CMS Important Changes Documentation HowTo .
A fix for a bug.
This tag may be used for changes that do not alter functionality, but try to improve code style and readability. Examples: coding guideline compliance, comment improvements
Anything not covered by the above categories. E.g. Refactoring of a component

Additionally other flags have to be added under certain circumstances:

Breaking change. After this patch, something works different than before and the user / admin / extension developer will have to change something. Has to be documented accordingly and should only be targeted for master branch. See TYPO3 CMS Important Changes Documentation HowTo.
Work In Progress. This flag will be removed, once the final version of a change is available. Changes marked WIP are never merged.
Visualizes that a change fixes a security issue. This tag is used by the Security Team, in case you found a security issues please always follow get in contact with the Security Team first!


Examples of topic descriptions

[BUGFIX] Throw HttpStatusExceptions in BackendController

[FEATURE] Add option to hide BE search box in list mod

[!!!][FEATURE] Implement new BE login form service

[!!!][TASK] Replace Foo API with new approach

[SECURITY] SQL Injection vulnerability in prepared statements

Note: The [!!!] prefix is added at the very beginning of the line, so it doesn't get overlooked.

Message body

  • Describe the problem and the change introduced by the Change Request. (The problem is already described in the Forge ticket.)
  • Keep it simple and don't repeat information that is already part of the issue tracker. Especially avoid "How to reproduce" part. At most, try to explain the change itself, if it is not already clear by reading the diff. Do not repeat the code change itself in the body text.
  • Wrap the lines after 72 characters manually
  • Write your commit message in the imperative present tense ("Fix bug" and not "Fixed bug"), since a commit is a set of instructions for how to go from a previous state to the new state and the commit message should describe this process. This convention matches up with generated commit messages by commands like git merge and git revert.



  1. The space after the colon (:) is mandatory. Otherwise the system will not properly update forge.
  2. If you have multiple resolved or related issues, use one line for each issue number.
  1. Resolves: For features and tasks, closes the issue on submit. Refer to the bug tracker entry at

    Resolves: #12345

    Historical : Some issues from the time since the introduction of GIT (March 1st 2011) and the migration of the bug tracker to Forge (March 29th 2011), still refer to Mantis bug tracker numbers, with a prefix the number with an M , i.e.:

    Resolves: #M12345
  2. Related: For all types, specifying simply a relation, no closing. Refer to the bug tracker entry at

    Related: #12345
  3. Releases: Refer to the branches for which this change will apply. This should be done on bugfixes which should be backported to older, still actively supported releases. Example:

    Releases: master, 7.6, 6.2
  4. Depends For TYPO3 documentation patches. Refer to the corresponding TYPO3 Core patch:

    Depends: ChangeIdOfCorePatch
  5. Change-Id: Do not write or change this line yourself. But keep the line once it exists.

    The change id is a randomly generated unique ID that identifies this change in the review system. The Change-Id line is automatically added by the git commit hook. The commit hook is executed when you have finished editing and save the commit message.

    Attention: Be sure to keep the existing Change-Id when adding a new patchset to an existing review. Use git commit --amend to do so.

Reverting patches

If there's the need to revert a patch, please add this information to the commit message:

  1. Add a Resolves-line for the ticket that is giving the reason for the revert.
  2. Add a Reverts-line for the ticket that belongs to the original patch.

Commit Template

You can use a custom template for getting done the commit message faster. All you need is the template like:



in a file, for example ~/.gitmessage.txt, and the command:

git config --global commit.template ~/.gitmessage.txt