Feature #13257

Define the rules for commit messages for TYPO3v4

Added by Ernesto Baschny over 8 years ago. Updated over 2 years ago.

Must have
Target version:
Start date:
Due date:
% Done:



We need to set up rules for our commit messages in GIT.

Here are the rules from the FLOW3 project:


And also the info about the used tags here:


Karsten mentioned that the experience from the usage of it until now makes it worth to refine or simplify it, and maybe we can then have a uniform standard for all our projects (FLOW3, Extbase, TYPO3v4).

Related issues

Related to git.typo3.org - Feature #13231: Link / Fix bugtracker items Closed 2011-02-21


#1 Updated by Karsten Dambekalns over 8 years ago

Yes, for me it is worth discussing the prefix, it could be dropped. The project name can go away, as we now have a repository per project.

#2 Updated by Ernesto Baschny over 8 years ago

You mean the whole prefix, or only the "one-char modifier"? I would suggest, instead of:

[~TASK] FLOW3 (MVC): Short (50 chars or less) summary of changes

We only have:

[TASK] Short (70 chars or less) summary of changes

Peter suggested not to use the long description at all. Instead make sure the issues being solved are well written and explained in the issue tracker. So that we don't get similar information spread on multiple places. If the original issue reporter has not explained the feature / bug well enough, its then the job of the patch submitter to update this text for a better explanation.

So in the long description we only have the issue tags left, e.g.:

Fixes: #1234
Fixes: #M1234
Resolves: #1234
Resolves: #M1234

About the prefix:

  • [!!!]
    • A breaking change that needs human action when updating.
    • A feature change. Most likely it will be an added feature, but it could also be removed. For additions there should be a corresponding ticket in the issue tracker.
  • [BUGFIX]
    • A fix for a bug. There should be a ticket corresponding to this in the issue tracker as well as a (new) unit test for the fix.
  • [API]
    • An API change, that is methods have been added or removed; method signatures or return types have changed. This only refers to the public API, i.e. methods tagged with @api (currently we still use it inverted, everything not in the public API is tagged @internal).
    • Some configuration change. That could be a changed default value, a new setting or the removal of some setting that used to exist.
  • [TASK]
    • Anything not covered by the above categories, e.g. coding style cleanup. Usually only used if there's no corresponding ticket.

#3 Updated by Ernesto Baschny over 8 years ago

When updating from one state to another, this new prefix would help:

  • [DB]
    • Something has changed in the database definition and would require a database COMPARE in the install tool

So for example if someone fixes a bug which changed a field definition, it would look like:

[BUGFIX][DB] Rised the size of field bla bla

BTW, to add a breaking change, it would look like this:

[API][!!!] Changed signature of method XYZ

#4 Updated by Ernesto Baschny over 8 years ago

  • Status changed from New to Resolved

Since there was no further feedback, and people are already starting to "use their own style", I decided to just go ahead and document it a bit more in detail:


Here I listed the tags I find appropriate and its usage. Feel free to open the discussion again (maybe through the mailing lists).

#5 Updated by Steffen Gebert over 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF