80

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?

Simon
  • 31,675
  • 9
  • 80
  • 92
Gandalf
  • 1
  • 29
  • 94
  • 165
  • 2
    http://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting – vijay Mar 10 '13 at 17:01
  • 8
    This question is not a duplicate of the one linked. This question asks about commit message content, whereas the linked question asks about a specific formatting practice. – Ajedi32 Jul 11 '14 at 18:37
  • See also: http://www.commitlogsfromlastnight.com/ and https://whatthecommit.com/ ... and of course https://www.reddit.com/r/ProgrammerHumor/comments/375fjr/whats_the_most_humorous_commit_message_youve_ever/ ;-) – Martin Thoma Nov 22 '17 at 11:25

3 Answers3

88

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.

Cometsong
  • 568
  • 9
  • 21
Ingo Karkat
  • 167,457
  • 16
  • 250
  • 324
  • 12
    +1 for emphasizing the ***why*** instead of the *how*. – Gady Oct 28 '14 at 00:13
  • 4
    @Bernard: That's just a dummy nonsense verb, as a placeholder. Origin in "frob" and "frobnicate" from the [Jargon file](http://www.catb.org/jargon/html/F/frob.html). – Ingo Karkat Apr 29 '16 at 06:12
  • 1
    + for [this funny slide](http://www.slideshare.net/TarinGamberini/commit-messages-goodpractices) – extempl Oct 01 '16 at 14:15
43

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
Jogge
  • 1,654
  • 12
  • 36
vijay
  • 2,646
  • 2
  • 23
  • 37
10

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.

mimipc
  • 1,354
  • 2
  • 14
  • 28
  • The underlying reason is also great to have: "Padding made Edge wrap the menu bar" or "Menubar fits better in sidebar than in header bar (UX rule 42)" – Xenos Jun 12 '18 at 14:54
  • 5
    Actually, in Git, you should use a message the makes it clear what the patch _will do_ when applied to a repository - not was _was_ done (more common in other vcs). Therefore `Fix padding bug` and `Add menu in sidebar` would be more conventional. See [Use the imperative mood in the subject line](https://chris.beams.io/posts/git-commit/#imperative) (and also see [Capitalize the subject line](https://chris.beams.io/posts/git-commit/#capitalize)) – friederbluemle Jan 29 '19 at 15:50