Labeling Messages and Change Sets

Question

I am looking for a solution to note changes in commit messages.

For me, a “tag” looks something like this:

• code cleaning
• user visible change
• changes the structure of the database (ALTER TABLE)
• Documentation Change

So far I am using SVN, but want to switch to git. If it were standard, many tools like trac, redmine, ... could use this.

I want this to answer the following questions:

• If I update the system, what changes are visible to the client, or is it just an update of the main content?
• Is the database schema changed between the two versions?

Background:

So far I have been using unison for synchronization between DEV, TEST and PROD systems. But unison knows nothing about version control (this is SVN for mummification). I want to switch to git. And I want to quickly see what the changes are.

Example: I want to see changes between TEST and PROD. I do not want to see source code changes, but commit messages. But sometimes up to 100 commits. Here I want a filter to exclude minor changes.

Answer 1

I like to use the following tags:

ADD adding new feature FIX a bug DOC documentation only REF refactoring that doesn't include any changes in features FMT formatting only (spacing...) MAK repository related changes (eg, changes in the ignore list) TEST related to test code only. 

This tag is always the first in a commit message, followed by a brief description and / or problem identifier from the problem tracking system, if one exists.

I use those tags with svn and git, and still found them very convenient.

To answer your edit: That's why I like those commit tags. This is immediately apparent if the commit changes behavior or not. If your database schema changes regularly, or if these changes are either very important to you, you can enter a tag for this.

I also like to combine tags in one message with a message where necessary. For example, "TEST DOC setup test foo".

With the optional DB tag for the database, you can easily track changes related to the database.

Answer 2

In most cases I use the tag system from Typo3: http://wiki.typo3.org/CommitMessage_Format_(Git)

It uses tags in commit messages as follows: [TAG] Short message Of course, I always appear in the problem number to track problems. We use JIRA to make it look like this: [TAG] JIRA-123 Short message

Tags Typo3:

Possible tags:

• [FEATURE]: new feature (also small additions). Most likely, this will be an added function, but it can also be removed. This can only happen in the v4 branch "master", as new functions are not allowed in the old branches. Exceptions to this should be discussed on a case-by-case basis with appropriate release managers.
• [BUGFIX]: bug fix.
• [TASK]: everything that does not belong to the above categories, for example. clear coding style.
• [API]: API has changed; methods or classes have been added or removed; Method signatures or return types have been changed. This applies only to the public TYPO3 API.

Additionally, under certain circumstances, other flags may be added:

• [!!!]: Violation of changes. After this patch, something works differently than before, and the user / admin / extension developer will have to change something. It can only happen on the "host".
• [WIP]: work continues. This flag will be removed after the final version of the change is available. Changes marked as WIP never merge.
• [SECURITY]: Renders that the changes fix the security issue. This tag is used by the security team. If you find a security problem, always make sure to contact the security team first!

Examples of topic descriptions:

• [BUGFIX] Throw HttpStatusExceptions at tslib_fe
• [BUGFIX] [SECURITY] SQL Injection Vulnerability in Prepared Operations
• [FEATURE] [CONF] Add an option to hide the BE search field in the mod list
• [!!!] [FEATURE] Move advanced editing interface to TER
• [!!!] [TASK] Delete t3lib_sqlengine
• [!!!] [API] Remove the redirected redirect () method from t3lib_userAuth
• [API] Creating an exception hierarchy for HTTP status exceptions

Answer 3

I prefer to assign a problem to my set of changes in my tracker problem. Using well-known problem trackers, such as jira, you can select a problem that is resolved in a set of changes. After selecting a problem, a description of the problem is automatically placed in the change set message. You can track them in the future, and also report them in your tracker problem.