Reading commit messages is a great way to understand software evolution without reading all the code.
I use the following rule:
- start with an action verb: Add, Fix, Remove, Update, Refactore...
- include the concerned domain (if != code): test, documentation, config, scripts...
- a description to explain the "Why?" or "How?"
- and a reference to ticket or bug
To obtain:
- Fix tests for Linux platform: filesystem was hardcoded - #123
- Add configuration: support article pagination - #345
- Refactore customer subscription service to improve performance - #898
And you, do you use any rules to write better commit message in your company or open source project ?
Top comments (14)
No swearing - we've had to give a dump of commits to a client previously.
No insults (self deprecating or otherwise) - or jokes - yes work should be fun but you just look unprofessional.
Reference the right ticket and we tend to put them first to make it easier to scan.
Try to avoid typos
Always write the commit so that you in a weeks time understands why they made the change (rather than what was changes)
Also compare individual file changes - don't bulk commit.
Only fix/create one thing between commits
Make sure that the commit compiles and works before commiting
Solid rules of thumb you've, thanks.
I'll note that commit messages are also something you may search for in the future, so conducting your own mini-SEO by thinking about keywords you or some other future person might think of is a plus.
I don't use Angular, but I practice something similar to Angular's commit message conventions:
Makes it easy to create logs out of it, too.
You can check examples in their commit log.
E.g.
From the
CONTRIBUTING.md
of our current project:Ideally, the commits should be as small and descriptive. As the user stories, the commits should ideally clarify what is it's purpose. A way to do that is to answer to this 4 questions:
With this in mind, no commit message should be less than 50 characters and should contain more than one line. This is not a strict rule, but by following the structure:
<id> - <how> <why> <side-effects>
It becomes easy to write more than 50 characters. For example:
My project enforces the structure of the commit message using githooks. The packages we use to enforce the commit message are
validate-commit-msg
(npmjs.com/package/validate-commit-msg) along withhusky
(npmjs.com/package/husky)It follows the Angular's commit message convention since
validate-commit-msg
was developed by some of their contributors.<type>(<scope>): <subject>
For Jira Users:
Don't forget to prefix your commit message with Jira Ticket ID.
You can view the same activity on Jira later on...
Ex:
MV-1234 added mySampleModule
No need to prefix, you can add Jira's ticket id to the commit body instead. Useful if you prefer to keep the commit title length below 80 characters.
Okay!! I tried once after comma,using below mentioned format but it didn't work. #needInputs
Ex. removed unRequiredModule, MV-1235 added actual implementation
I do it like this, and Jira seems to be able to pick it up:
Taken, I'll try. Thanks for correcting :)
The best tool ever to create a neutral and understandable commit message is this sentence: "If you apply this commit to your code, it will [this part becomes the commit title]".
I try to keep the title length below 74 characters, and try to remove words like "the" from it. Then a blank line, then the commit body in one paragraph, no line breaks, describing in better detail what and why the commit. Then the Jira issue ID on the last line.
I used this when I'm working with JIRA, [Ticket ID] : [Descriptive message of what the commit fixes]
[fix|chore|refactor|feat]: [title of work item that was addressed]