Skip to content

Instantly share code, notes, and snippets.

@antonlvovych
Last active November 15, 2017 20:26
Show Gist options
  • Save antonlvovych/ade4a6f92a171fbabefa to your computer and use it in GitHub Desktop.
Save antonlvovych/ade4a6f92a171fbabefa to your computer and use it in GitHub Desktop.
Convention for git commit messages
EXAMPLE OF FULL-FETURED COMMIT MESSAGE:
================================================================================
EMKT-0000: Summarize changes in around 50 characters or less | <-- COMMIT SUBJECT
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 the commit 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); various tools like `log`, `shortlog` and `rebase` |
can get confused if you run the two together. |
| <-- COMMIT BODY
Explain the problem that this commit is solving. Focus on why you are |
making this change as opposed to how (the code explains that). Are there |
side effects or other unintuitive consequenses of this change? Here's |
the place to explain them. |
|
Further paragraphs come after blank lines. |
CONVENTION:
================================================================================
1. COMMIT SUBJECT
1.1 Use ticket name if exists as in example above
1.2 Limit the subject line to 50 characters
1.3 Separate subject from body with a blank line
1.4 Capitalize the subject line
1.5 Do not end the subject line with a period
1.6 Use the imperative mood in the subject line
Imperative mood just means "spoken or written as if giving a command or
instruction".
A few examples:
- Clean your room
- Close the door
- Take out the trash
1.7 A properly formed git commit subject line should always be able to
complete the following sentence:
If applied, this commit will <your subject line here>
Good:
- If applied, this commit will refactor subsystem X for readability
- If applied, this commit will update getting started documentation
- If applied, this commit will remove deprecated methods
Bad:
- If applied, this commit will more fixes for broken stuff
- If applied, this commit will don't ask me why I did it...
- If applied, this commit will sweet new API methods
2. COMMIT BODY
2.1 Wrap the body at 72 characters
2.2 Use the body to explain what and why vs. how
This commit from Bitcoin Core (goo.gl/J8yZaD) is a great example of
explaining what changed and why:
-------------------------------------------------------------------
commit eb0b56b19017ab5c16c745e6da39c53126924ed6
author: Pieter Wuille <pieter.wuille@gmail.com>
date: Fri Aug 1 22:57:55 2014 +0200
Simplify serialize.h's exception handling
Remove the 'state' and 'exceptmask' from serialize.h's stream
implementations, as well as related methods.
As exceptmask always included 'failbit', and setstate was always
called with bits = failbit, all it did was immediately raise an
exception. Get rid of those variables, and replace the setstate
with direct exception throwing (which also removes some dead
code).
As a result, good() is never reached after a failure (there are
only 2 calls, one of which is in tests), and can just be replaced
by !eof().
fail(), clear(n) and exceptions() are just never called. Delete
them.
-------------------------------------------------------------------
NOTE:
This document is under development, so all your suggestions will be discussed.
For more information about GIT you can also visit: git-scm.com
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment