I have been tagging and categorising my Git code commits for years. That helps everybody identify the nature of a particular commit, and encourages more frequent commits by breaking and grouping the changes into smaller and more meaningful segments.
I have modified the format a bit by referencing this website:
https://sparkbox.com/foundry/semantic_commit_messages
Since the projects I work on do not usually involve a large team of people, and actually, we do not have the resources to complicate the development process, a commit message is set to be a single line which consists of the following:
[<type>] <scope>: (<referencing issues>) <description>Options for <type>
- feature (new feature for the user, not a new feature for build script)
- fix (bug fix for the user, not a fix to a build script)
- docs (changes to the documentation)
- style (formatting, missing semi-colons, etc.; no production code change)
- refactor (refactoring production code, e.g. renaming a variable)
- test (adding missing tests, refactoring tests; no production code change)
- chore (updating grunt tasks etc.; no production code change)
Most admin work falls under this category. For example, tool changes, configuration changes, and changes to things that do not go into production.
In the past, [test], [docs] and [style] have been tagged as [chore]. This will be changed in new projects.
Usage of <scope>
- The <scope> can be empty (e.g. if the change is global or difficult to assign to a single component)
- For Android, it can be the name of a package, a class, or a module on system design specifications
Usage of <referencing issues>
- <referencing issues> can be empty
- If the project has a project management/bug tracker linked, this will be the issue number. This is for associating the changes with the related entry.
- For a [feature] commit, this can be the module number if we have system design specifications
The rules for <description>
- I used past tense originally, and this has been changed since 2020.
- Now I use the imperative, present tense. For example, “change”, not “changed” nor “changes”
- Being clear and concise is more important than being grammar police.
Example
[feature] MainActivity: (#2806) add broadcast receiver
[style] remove redundant line breaks
[refactor] Viewholders: rename memberId to userId
[fix] PaymentActivity: (#4231) fix Null Pointer Exception when decoding json string
[chore] update build.gradleThis can be very useful to quickly identify the effort spent on implementing new features, fixing bugs and doing admin work.
