Recommended format for Git commit messages

What is the recommended for开发者_StackOverflow中文版mat for Git commit messages, if there is any?

---

It varies, of course, but a very common format is something like this (taken from http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html, that I think sums it up really well):

Short (50 chars or less) summary of changes

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.

Further paragraphs come after blank lines.

 - Bullet points are okay, too

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

One thing it doesn't address is something I've adopted for myself, namely using short tags at the start of the firstt line to identify what kind of commit it is. That might be tags like [fix] for a bugfix, [new] for a new feature or [dev] for a commit that only affects internals. With a policy like that, it's easy to autogenerate a changelog from the commits.

Edit: Here's another good summary, from this site even: In git, what are some good conventions to format multiple comments to a single commit

---

I would not recommend large messages. If you can't explain in one sentence what you are doing, your commit encompasses too much change. Use git rebase -i and split up your commit if you already committed. If you have not committed the changes yet, use git add -p to stage in small parts and then commit as smaller commits.

A granular change history like this will help subsequent merges and rebases. It will also help you link to your issue tracker. If you have 2 or more tickets addressed, it will be more difficult to decipher what ticket each change in the commit addressed.

---

The commit diff describes a change in the project text (syntactic change) whereas the commit message describes a change in the project meaning (semantic change).

Commit message format:

• The first line describes the semantic change and its scope. It is limited to 50 characters, written in imperative mood, and does not end with a period.
• The next line is empty.
• The remaining lines describe the semantic context before and after the semantic change and its limitations. They are wrapped at 72 characters.

Commit message examples:

Percent-encode requests_mock URIs in API tests

Before this change, 32 API tests failed with the default .env file 
because it contains the characters ‘<’ and ‘>’ (used as variable 
delimiters) which are automatically percent-encoded in requests URIs (as 
those characters are not allowed in URIs) but not in requests_mock URIs.

After this change, all tests will pass with the default .env file.

This change does not percent-encode URIs in non-failing tests.

Add a company selection page in HTML templates

Before this change, users logged in to different accounts by entering 
different credentials in the login page.

After this change, users will log in to different accounts by entering 
the same credentials in the login page and selecting different companies 
in the company selection page.

This change does not allow logged in users to switch account without 
logging out.

References:

• https://www.git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines
• https://google.github.io/eng-practices/review/developer/cl-descriptions.html
• https://wiki.openstack.org/wiki/GitCommitMessages
• http://who-t.blogspot.com/2009/12/on-commit-messages.html
• https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
• https://cbea.ms/git-commit/