Standard to follow when writing git commit messages [duplicate]
Solution 1:
When you just describe what you've done (in technical yet fuzzy terms like "added a function"), you're not adding much to what Git already stores in the commit. Imagine yourself reading the commit message some time later; what kind of summary would help you most remembering / communicating to other developers the essence of that change?! The exact contents depend on your project and processes, but I find that a good guideline.
Therefore, first and foremost add context (the why, not the how) with your commit message (e.g. "frobnize the message to enable persistence") instead of "added frob() function"). It's more effort (you have to reflect and think), but it is worth so much more.
If you want to explore more about this topic, there's a wealth of information, for example this blog article by Peter Hutterer or this funny slide.
Solution 2:
The 50/72 model seems to be a good practice. i.e. ... the first line should be maximum 50 chars long and should server as a header. Followed by a space, the second set of line(s) should be wrapped at 72 chars and should serve as a summary. Here is a SO question : Git Commit Messages : 50/72 Formatting, that discusses the same.
Here are some exhaustive notes on the subject:
- GIT Commit Good Practice
- A Note About Git Commit Messages
- Proper Git Commit Messages and an Elegant Git History
Solution 3:
Git already knows which files you modified in a commit, it's useless to specify it in the comment. Just say for example "fixed padding bug" or "added menu in sidebar". Make it clear, that's it.