Standard to follow when writing git commit messages [duplicate]

Question

This question already has answers here:

Git Commit Messages: 50/72 Formatting (5 answers)

Closed 7 years ago.

I find myself managing very many files (over 60 but below 70) and my commit messages so far follow this pattern: when I have added something like on layout.css, my commit message is "added something on layout.css file", and when I remove something, my commit message is "removed something from layout.css file".

Some files down the line, I look at my commits feed and added... and removed... messages dominate. Sometimes I don't remember what I removed or what I added in layout.css since I make so many changes at a go and so I struggle to come up with an appropriate commit message.

Is there a standard I should follow to help me come up with my commit messages?

Answer 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.

Answer 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:

1. GIT Commit Good Practice
2. A Note About Git Commit Messages
3. Proper Git Commit Messages and an Elegant Git History

Answer 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.