update gitmessage
parent
5b43399ad1
commit
e988201e22
|
|
@ -1,7 +1,31 @@
|
|||
# [Add/Fix/Remove/Update/Refactor/Document] [issue #id] [summary]
|
||||
|
||||
# ^ [issue #id] [Add/Fix/Remove/Update/Refactor/Document] [summary] ^
|
||||
|
||||
# Why is it necessary? (Bug fix, feature, improvements?)
|
||||
|
||||
# How does the change address the issue?
|
||||
|
||||
# What side effects does this change have?
|
||||
|
||||
# Rationale:
|
||||
# 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.
|
||||
#
|
||||
# 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
|
||||
#
|
||||
# - Typically a hyphen or asterisk is used for the bullet, followed by a
|
||||
# single space, with blank lines in between, but conventions vary here
|
||||
#
|
||||
# - Use a hanging indent
|
||||
# Read more @ https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
|
||||
|
|
|
|||
Loading…
Reference in New Issue