Define the rules for commit messages for TYPO3v4
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).
#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.
- 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.
- 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.
- 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:
- 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).