Standard to follow when writing git commit messages [duplicate]

Question

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.