-
Notifications
You must be signed in to change notification settings - Fork 2
/
.commit_template
39 lines (38 loc) · 1.63 KB
/
.commit_template
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
# === Format (CC1.0.0)
#
# ```
# <type>[optional scope]: <description>
#
# [optional body]
#
# [optional footer(s)]
# ```
#
# === Conventional Commits 1.0.0
#
# https://www.conventionalcommits.org/en/v1.0.0/
# https://www.conventionalcommits.org/ja/v1.0.0/
#
# The commit contains the following structural elements,
# to communicate intent to the consumers of your library:
#
# 1. fix: a commit of the type fix patches a bug in your codebase
# (this correlates with PATCH in Semantic Versioning).
# 2. feat: a commit of the type feat introduces a new feature to
# the codebase (this correlates with MINOR in Semantic Versioning).
# 3. BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:,
# or appends a ! after the type/scope, introduces a breaking API
# change (correlating with MAJOR in Semantic Versioning).
# A BREAKING CHANGE can be part of commits of any type.
# 4. types other than fix: and feat: are allowed, for example
# @commitlint/config-conventional (based on the the Angular convention)
# recommends build:, chore:, ci:, docs:, style:, refactor:,
# perf:, test:, and others.
# 5. footers other than BREAKING CHANGE: <description> may be provided
# and follow a convention similar to git trailer format.
#
# Additional types are not mandated by the Conventional Commits specification,
# and have no implicit effect in Semantic Versioning (unless they include a
# BREAKING CHANGE). A scope may be provided to a commit’s type, to provide
# additional contextual information and is contained within parenthesis,
# e.g., feat(parser): add ability to parse arrays.