Following is the template I generally refer to.
FEATURE/BUGFIX/ENHANCEMENT: KonyOne Studio - <Module name> - <short problem/module description>
<Detailed description of feature/solution description/enhancement comments>
<Fix: #JSP1234>
Reviewed By : <reviewer name>
Example for Feature:
FEATURE: KonyOne Studio - Sky Data Explorer - Implemented model classes for sky explorer
Provided the offline support capabilities to work offline.
Reviewed by: Rakesh
Example for BugFix:
BUGFIX: KonyOne Studio - Java Script Module - Heap memory issues with huge number of files.
Java script listener is modified..etc,..
Fix: #JSP12345
Example for Enhancement:
ENHANCEMENT: KonyOne Studio - Java Script Module - code clean for java script model
Unnecessary code has been removed in java script module.
Reviewed by: Rakesh
Points to be considered:
- Topic description (first line)
- 72 characters max for each line.
- Give space for title and body
- Use present tense.(Generally git uses the same for merge/rebase)
Why 72 characters ??
git log doesn’t do any special special wrapping of the commit messages.
On an 80 column terminal, if we subtract 4 columns for the indent on the left and 4 more for symmetry on the right, we’re left with 72 columns.
Good commit messages serve at least three important purposes:
- To speed up the reviewing process.
- To help us write a good release note.
- To help the future maintainers of Erlang/OTP (it could be you!), say five years into the future, to find out why a particular change was made to the code or why a specific feature was added.
