dotfiles/.gitmessage at master · bdossantos/dotfiles · GitHub

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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75


# Conventional Commits
# ====================
#
# Each commit message consists of a header, a body and a footer. The header has
# a special format that includes a type, an optional scope and a description:
#
# <type>[optional scope]: <description>
# <BLANK LINE>
# <body>
# <BLANK LINE>
# <footer(s)>
#
# The header is mandatory; the scope is optional. Append `!` after the type or
# scope to indicate a breaking change:
#
# <type>[optional scope]!: <description>
#
# Any line of the commit message cannot be longer than 100 characters. This
# allows the message to be easier to read on GitHub as well as in various git
# tools.
#
# Type
# ====
#
# - build: changes that affect the build system or external dependencies
# - ci: changes to CI configuration files and scripts
# - docs: documentation only changes
# - feat: a new feature (correlates with MINOR in Semantic Versioning)
# - fix: a bug fix (correlates with PATCH in Semantic Versioning)
# - perf: a code change that improves performance
# - refactor: a code change that neither fixes a bug nor adds a feature
# - revert: reverts a previous commit
# - style: changes that do not affect the meaning of the code (white-space,
#   formatting, missing semi-colons, etc.)
# - test: adding missing tests or correcting existing tests
#
# Scope
# =====
#
# The scope provides additional contextual information and can be anything
# specifying the place of the commit change (e.g. bash, vim, tmux, git, ssh).
#
# Description
# ===========
#
# The description is a short summary of the code changes:
#
# - use the imperative, present tense: "change" not "changed" nor "changes"
# - don't capitalize the first letter
# - no dot (.) at the end
#
# Body
# ====
#
# The body should include the motivation for the change and contrast this with
# previous behavior. Use the imperative, present tense: "change" not "changed"
# nor "changes".
#
# Footer
# ======
#
# One or more footers may be provided. Each footer token must use `-` in place
# of whitespace, e.g. `Reviewed-by`. The exception is `BREAKING CHANGE` (or
# its synonym `BREAKING-CHANGE`), which may also be used as a footer token.
#
# A breaking change MUST be indicated either by a `!` in the header or by a
# `BREAKING CHANGE: <description>` footer (correlates with MAJOR in Semantic
# Versioning). Both may be used together.
#
# The footer is also the place to reference issues that this commit closes,
# e.g. `Closes #123`.
#
# Specification: https://www.conventionalcommits.org/en/v1.0.0/