Open rudimusmaximus opened 6 years ago
Feedback sought with links to this issue:
Agree on removing sem ver and signature from message format.
subjectLineType
: Summarize changes in around 50 characters or less
Subject line types are
feat
, fix
, docs
, style
, refactor
, test
, and chore
.
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.
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 consequences of this change? Here's the place to explain them.
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
If you use an issue tracker, put references to them at the bottom, like this:
See also: #
number, #
anotherIssue OR no line at all
This article explains how to setup your own global git commit message template or to do so locally for your repo. article about git commit templates code commit template
The latest GitKraken allows for removing comment lines from your commit messages (these start with #). So, in your prefereces at least for one repo. it looks like this.
For info about setting globally see the links in the previous block.
subjectLineType: SummarizeChangesInAround50CharsOr
#
#
#
#
#
#
My current default git commit is
subjectLineTypes: { feat fix docs style refactor test chore }
# More detailed explanatory text, if necessary. Wrap it to about 72
# characters or so.
#
# 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 non-intuitive consequences of this
# change? Here's the place to explain them.
#
# 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
#
# If you use an issue tracker, put references to them at the bottom,
# like this:
#
# Resolves: #123 [DO NOT use GitHub issue close language if running sprints using ZenHub Here]
# See also: #number, #anotherIssue OR no line at all
use this with the subject moved into the subject line and tell GKraken to remove # comment lines
objective / purpose
Formalize git commit style for DevFlow.
completion checklist
POST LIVE:
full pipeline documentation
Overview - describe with history and related items
Referencing style guides for Udacity nanodegree front end web developers, modify contributing.md with an adapted template for DevFlow. These are not automated, so add a check for consistency in the default issue lifecycle.
See these from Udacity course notes:
Solution Design
Adapted from Udacity Git Style Guide for this DevFlow.
issues.md
We need this new checklist item in the issue lifecycle.
contributing.md
Add a section in contributing based on Git commit style guide above.
body
footer
feat: Summarize changes in around 50 characters or less
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
andrebase
can get confused if you run the two together.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 consequences of this change? Here's the place to explain them.
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
If you use an issue tracker, put references to them at the bottom, like this:
Resolves: #123 [DO NOT use GitHub issue close language if running sprints using ZenHub Here] See also: #456, #789
n/a