diff options
Diffstat (limited to 'wiki/dev/commit-messages.md')
| -rw-r--r-- | wiki/dev/commit-messages.md | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/wiki/dev/commit-messages.md b/wiki/dev/commit-messages.md index 6661671..6b3702d 100644 --- a/wiki/dev/commit-messages.md +++ b/wiki/dev/commit-messages.md @@ -1,6 +1,6 @@ # Writing Good Commit Messages -Rule zero: "good" is defined by the standards of the project you're on. Have a +Rule zero: “good” is defined by the standards of the project you're on. Have a look at what the existing messages look like, and try to emulate that first before doing anything else. @@ -8,13 +8,13 @@ Having said that, here are some things that will help your commit messages be useful later: * Treat the first line of the message as a one-sentence summary. Most SCM - systems have an "overview" command that shows shortened commit messages in + systems have an “overview” command that shows shortened commit messages in bulk, so making the very beginning of the message meaningful helps make those modes more useful for finding specific commits. _It's okay for this to - be a "what" description_ if the rest of the message is a "why" description. + be a “what” description_ if the rest of the message is a “why” description. * Fill out the rest of the message with prose outlining why you made the - change. The guidelines for a good "why" message are the same as [the + change. The guidelines for a good “why” message are the same as [the guidelines for good comments](comments), but commit messages can be signifigantly longer. Don't bother reiterating the contents of the change in detail; anyone who needs that can read the diff themselves. @@ -27,8 +27,8 @@ useful later: of the way, such as on a line of its own at the end of the message. * Pick a tense and a mood and stick with them. Reading one commit with a - present-tense imperative message ("Add support for PNGs") and another commit - with a past-tense narrative message ("Fixed bug in PNG support") is + present-tense imperative message (“Add support for PNGs”) and another commit + with a past-tense narrative message (“Fixed bug in PNG support”) is distracting. * If you need rich commit messages (links, lists, and so on), pick one markup |