antonlvovych · November 15, 2017 20:26 · Jul 6, 2015 · Jul 6, 2015 · Jul 6, 2015
diff --git a/git-convention b/git-convention
@@ -3,7 +3,6 @@ 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               |

diff --git a/git-convention b/git-convention
@@ -26,7 +26,7 @@ CONVENTION:
 
 1. COMMIT SUBJECT
 
-   1.1 Use ticket name if exists as in example below
+   1.1 Use ticket name if exists as in example above
 
    1.2 Limit the subject line to 50 characters
 

diff --git a/git-convention b/git-convention
@@ -0,0 +1,102 @@
+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 below
+
+   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 <[email protected]>
+       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
No results found