I follow the convention that is being applied in my company:
For me, referring the request number is enough. If I want more detail, I take a look at the request itself.
I use the format from this project and I find it incredibly useful when you are skimming through the commits.
Each commit message should include a type, a scope and a subject: <type>(<scope>): <subject> Lines should not exceed 100 characters. This allows the message to be easier to read on github as well as in various git tools and produces a nice, neat commit log ie:
#271 feat(standard): add style config and refactor to match
#270 fix(config): only override publicPath when served by webpack
#269 feat(eslint-config-defaults): replace eslint-config-airbnb
#268 feat(config): allow user to configure webpack stats output
Type
Must be one of the following:
Scope
The scope could be anything specifying place of the commit change. For example webpack,
babel, redux etc...
Subject
The subject contains succinct description of the change:
I always use a "tag" (upercase) and a "title" in the beginning of the message like:
This way I recognize what is about faster than reading all the message. Then the explanation using present tense. For example:
SPRINT-2. Google drive integration. Users can upload files using the google drive picker to a post
Keep it concise, short and to the point.
If somebody reads your commit message, they should know what the commit was about, so put yourself in somebody else's shoes after you've written your commit message and see if you understand it.
I follow the Atom style guide for commit messages. A brief overview of the rules:
I always run a commit after I have made significant progress. It depends for me, sometimes it might be a simple file change(like fixing a typo), most times it is when I get something to work before I commit. Most importantly, I try to make my commits easy to understand(use present tense).
Cliff Rowley
Thinker, Tinkererer, Dork.
Krishna Shukla
hotmail.co.uk