This article - http://chris.beams.io/posts/git-commit/ - is what I go along with, as a guideline.
It would be great to see if you have any advice on doing it any differently, or simply, on how you prefer to do it; whether you use any custom tools that aid you in anyway. Personal "git-commit-message" stories of triumph would be super swell too. :)
The true standard is: get your team to agree on something, then enforce it. Whatever works for your team is the right thing. The problem is rarely the standard, it's when individuals refuse to follow the standard used by the rest of the team.
Current standard at work: prefix your commit with the issue key associated with the change, then add a short description of the change in that commit. We use JIRA so that means:
JIRA-123 Refactored foo() behind the API
JIRA-456 Changed colours to new palette
Couple of considerations:
Hmm i see your point. The truth is if you commit code a bunch of times on a regular basis for 3-4 projects it is hard to pay that much attention in there. A short descriptive message is ok for me. I don't know, i don't use sth like a pattern in there. If this makes me a sloppy developer i have to confess guilty!!
Think of your message as a headline that says in few words what you did, people can always see the changes or you can add a detailed message along the headline
Nope, I commit too much code a day to care about a commit spec. Just put a clear message in there and make sure somebody can understand what your commit message means.
sujesh thekkepatt
Here is an interesting blog American Express. The format explained here is from Conventional Commit. I think having such a standard is very important. One line commits messages like "bug fix", "updated fix" etc should be avoided.