On behalf of me and all of you who are software developers, everyone surely knows and understands Git. Git plays an important role in the daily work of every programmer, and what is even more important for all of you is setting your commit message.
Remember that every time you finish a task, you should write down a note and explain what you did. Therefore, today I will show you how to write a good message for every programmer that should be implemented to be better.
NOTE: The prefix is all CAPITAL letters surrounded by [BRACES].
[FEATURE]
A feature change. It will be an added or removed feature. 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, and we encourage you to add a new test that exposes the bug, which makes the work for everyone easy in the future and prevents the bug from reappearing.
[RFT]
A code refactoring. It does not fix any bugs and implements new features. The functionality is the same but you make some changes to make the performance better or reorganize code easier to understand.
[IMP]
An improvement, Less focused on code refactoring. It could be removing unused code, a coding guideline or anything that makes the task or feature better.
[DOC]
Documentation. While the documentation for a feature usually comes with the feature commit. It could cover the features missing the documentation, the adjustment to the documentation. It is also for adding/updating the README file or any other manuals.
[TASK]
Anything that is not covered by the above categories. Usually only used if there is no corresponding ticket.
[SECURITY]
A security-related change.
NOTE: Never commit with this command: git commit -m "[commit message]" because you cannot provide a proper explanation.
+ Message Summary
- The code is followed by a summary in the same line, with no Full Stop (.) at the end.
- It must start with A CAPITAL letter, and there is a [SPACE] between the prefix and the message.
- The summary length should be 50 characters or less.
- If the change affects the public API or is likely to break things on the user side, prefix the line with [!!!].
- An indicates a breaking change that needs human action when updating.
- Make sure to explain why a change is breaking and in what circumstances.
The description explains what was done. It should answer the following question below:
- Why was this change necessary?
- How does it address the problem?
- Are there any side effects?
Example:[TASK]CRUD User table
0 Comments