Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 17 additions & 15 deletions book/05-distributed-git/sections/contributing.asc
Original file line number Diff line number Diff line change
Expand Up @@ -59,30 +59,32 @@ The last thing to keep in mind is the commit message.
Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier.
As a general rule, your messages should start with a single line that's no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation.
The Git project requires that the more detailed explanation include your motivation for the change and contrast its implementation with previous behavior -- this is a good guideline to follow.
It's also a good idea to use the imperative present tense in these messages.
In other words, use commands.
Instead of ``I added tests for'' or ``Adding tests for,'' use ``Add tests for.''
Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug."
Here is a https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[template originally written by Tim Pope]:

[source,text]
----
Short (50 chars or less) summary of changes
Capitalized, short (50 chars or less) summary

More detailed explanatory text, if necessary. Wrap it to
about 72 characters or so. In some contexts, the first
line is treated as the subject of an email and the rest of
the text as the body. The blank line separating the
summary from the body is critical (unless you omit the body
entirely); tools like rebase can get confused if you run
the two together.
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.

Write your commit message in the imperative: "Fix bug" and not "Fixed bug"
or "Fixes bug." This convention matches up with commit messages generated
by commands like git merge and git revert.

Further paragraphs come after blank lines.

- Bullet points are okay, too
- Bullet points are okay, too

- Typically a hyphen or asterisk is used for the bullet, followed by a
single space, with blank lines in between, but conventions vary here

- Typically a hyphen or asterisk is used for the bullet,
preceded by a single space, with blank lines in
between, but conventions vary here
- Use a hanging indent
----

If all your commit messages follow this model, things will be much easier for you and the developers with whom you collaborate.
Expand Down