-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy path.gitmessage
81 lines (79 loc) · 4.18 KB
/
.gitmessage
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
76
77
78
79
80
81
# <type>(<scope>)!: <description> (72 characters maximum)
# |<--- preferably using up to 50 characters --->|<------------------->|
#
# Optional <body>
# |<------------------- wrap lines at 72 characters ------------------>|
#
# Optional <footer>
#
# ----- END COMMIT MESSAGE -----
#
# Conventional Commits Cheatsheet (https://www.conventionalcommits.org)
#
# <type> indicates what kind of commit this is.
# It can be one of:
# - feat for new features introduced (i.e. MINOR in SemVer standard)
# - fix for bug-fixes (i.e. PATCH in SemVer standard)
# - build for changes in build system or environment
# - ci for configuring continuous integration systems
# - test for adding new tests or correcting defective tests
# - docs for changes in documentation only
# - refactor for rewriting or restructuring of code that does not affect API behavior
# - perf for performance-enhancing refactors
# - style for changes in code styles and no changes in logic
# - chore for miscellaneous tasks
# - revert for reverting commits made previously
#
# <scope> describes a section of the codebase where this change is applied and is optional.
# Note that allowed content of this section depends on the specific project.
# Issue identifiers are not valid scopes.
#
# Inserting "!" before the colon indicates that this commit introduces a breaking change.
# It is equivalent to a bump in MAJOR in SemVer standard.
# With this, the breaking change indicator in <footer> becomes optional.
#
# <description> contains a conceise description of the change.
# The content should be in imperative mood, as if "This commit will..." is prepended.
# Do not capitalize the beginning of the sentence, and full stop (.) is omitted.
#
# <body> provides additional contextual information about the code changes and is optional.
# Mutliple paragraphs separated by an empty line are allowed here.
# Sentences should be in imperative mood with proper capitalization and full stops (.).
#
# <footer> is a list of key-value pairs that store "metadata" of a commit.
# There are three types of a footer:
# - Breaking change indicator verbatim "BREAKING CHANGE:", followed by a <description>
# - Automatic issue management such as "Close #123", "Reference #123", "See #123", etc.
# - Email-like metadata such as "Signed-off-by:", "Co-authored-by", etc.
#
# There are three exceptions to the subject line rules:
# 1. "Initial commit" for the first commit in a git repository
# 2. "Merge branch..." as it is the default commit message for automatic merges
# 3. "Revert..." as it is the default commit message for reverting commits
#
#
# ODOO GUIDELINES:
#
# Tags are used to prefix your commit. They should be one of the following
# - [FIX] for bug fixes: mostly used in stable version but also valid if you are fixing a
# recent bug in development version;
# - [REF] for refactoring: when a feature is heavily rewritten;
# - [ADD] for adding new modules;
# - [REM] for removing resources: removing dead code, removing views, removing modules, …;
# - [REV] for reverting commits: if a commit causes issues or is not wanted reverting
# it is done using this tag;
# - [MOV] for moving files: use git move and do not change content of moved file otherwise
# Git may loose track and history of the file; also used when moving code from one file
# to another;
# - [REL] for release commits: new major or minor stable versions;
# - [IMP] for improvements: most of the changes done in development version are incremental
# improvements not related to another tag;
# - [MERGE] for merge commits: used in forward port of bug fixes but also as main commit
# for feature involving several separated commits;
# - [I18N] for changes in translation files;
# - [MIG] for migrating a module;
#
# After tag comes the modified module name. Use the technical name as functional name may change with time.
# If several modules are modified, list them or use various to tell it is cross-modules.
# Unless really required or easier avoid modifying code across several modules in the same commit.
# Understanding module history may become difficult.