From c5db1778c3f19c66cd3ef7719c52a6a6a17e2d17 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Eric=20Garc=C3=ADa=20Cano?= Date: Thu, 9 Jul 2020 20:03:52 -0400 Subject: [PATCH 1/9] Update README.md --- README.md | 86 +++++++++++++++++++++++-------------------------------- 1 file changed, 36 insertions(+), 50 deletions(-) diff --git a/README.md b/README.md index d94eea4..c8ea392 100644 --- a/README.md +++ b/README.md @@ -1,66 +1,56 @@ -Commit message format (version 1.7) -=================== +Alternative Commit Message Format (version 0.9) +============================================= ##What is it? -This is a proposal of tags to be used in commit messages. The goal is to identify easily the different types of changes in the project's repo. +This is a proposal of labels (expressions enclosed in square brackets) to be used in commit messages. The goal is to identify easily the different types of changes in a repo. ##Commit Message rules -####Subject desription (first line) ->1. Prefix the line with an applicable emoji (tag) ->2. Limit the subject line to 50 characters ->3. Separate subject from body with a blank line ->4. Capitalize the subject line ->5. Do not end the subject line with a period ->6. Use the imperative mood in the subject line +Common layout for a commit message +``` +[tag>subtag] subject description + +body: used to explain the what and why of a commit, not the how. Wrap the body at 72 characters in each line. -####Message body ->7. Wrap the body at 72 characters ->8. Use the body to explain the problems, limitations, and why it is necessary. Then to explain how was addressed the issue and the effects. +footer: used to reference issue tracker IDs. +``` + +####Subject desription (first line) +>1. Prefix the line with an applicable label +>2. Limit all the lines (subject included) to 72 characters +>3. Use the imperative tone in the subject line +>4. Separate subject from body with a blank line +>5. Capitalize the subject line +>6. Do not end the subject line with a period A complete description, rules and tips can be seen in [1]. -####Tags and meaning for source code +####Main tags and meaning for source code **NOTE:** The first commit does not have a label, and the message always is "**Initial commit**" as convention. ->* [api] when functions, methods or classes have been added, modified or removed; method signatures or return types have changed ->* [code] when improving the format/structure of the code, without modifying the previous functionality +>* [core] when functions, methods or classes have been added, modified or removed; method signatures or return types have changed +>* [style] when improving the format/structure of the code, without modifying the previous functionality >* [main] when dealing with a file that is used as view, notebook or main file ->* [misc] anything not covered by the above categories, e.g. rename or move files, add configuration files, add dataset >* [new] when adding a new feature (see *Rules* section) >* [pkg] when libraries, frameworks, packages or modules are added ->* [style] when writing documentation, formatting or comments on code; no code change +>* [docs] when writing documentation, formatting or comments on code; no code change >* [test] when adding tests, refactoring tests; no production code change +>* [misc] anything not covered by the above categories, e.g. rename or move files, add configuration files, add dataset +####Sub-labels +Those sub-labels are used in order to provide the action that the commit does +>Example: +> [core>add] Subject description -####Tags and meaning for database - ->* [ak] alternate key ->* [chk] check restriction ->* [col] column ->* [dt] data type ->* [fk] foreign key ->* [idx] index ->* [mv] materialize view ->* [pk] primary key ->* [seq] sequence ->* [tbl] table ->* [trg] trigger ->* [vw] view - -####Subtags -Those subtags are used in order to provide the action that the commit does >* *add* when something new has been added +>* *modify* when changes in files have been made >* *boost* when improving performance ->* *bug* when a bug is found (see *Rules* section) >* *fix* when fixing a bug (see *Rules* section) ->* *modify* when changes in files have been made >* *move* when files are moved between directories >* *remove* when files or directories are deleted >* *rename* when files or directories are renamed ->* *update* when a package's version is changed, module is added, removed or modified (see *Rules* section) - +>* *update* when a package's version is changed or updated(see *Rules* section) When fixing something on: >* *and* (*Android*) @@ -69,21 +59,17 @@ When fixing something on: >* *macos* >* *win* - -Those subtags must be used just in combination with other tags to specify a particular change related to an O.S. +Those sub-labels must be used just in combination with other label to specify a particular change related to an O.S. or a comma-separated operating systems. >Example: -> [api>macos] Subject description +> [api>add|macos] Subject description ####Rules -1. The tag [new] is only used when you are doing a merge between a feature-branch and develop. - -2. The tag [update] must be used just when a package is updates ([pkg|update]). - -3. Sometimes when you are doing modifications on your source code, it is likely to find a bug, in this case two actions can occur: +1. The label [new] is only used when you are doing a merge between a change-branch and source branch. ->+ [api>modify+bug] when the code was modified, a bug was found but NOT fixed ->+ [api>modify+fix] when the code was modified, a bug was found and WAS fixed +2. The sub-label [update] must be used just when a package is updates ([pkg>update]). +3. Sometimes when you are doing modifications on your source code, it is likely to find a bug, in this case, after fixed it: +>+ [api>modify+fix] the code was modified: a bug was found and WAS fixed ##REFERENCES @@ -94,4 +80,4 @@ Those subtags must be used just in combination with other tags to specify a part 4. [Karma](http://karma-runner.github.io/0.8/dev/git-commit-msg.html) ------------- -This document was last modified on : April 6th, 2016. +This document was last modified on : July 9th, 2020. From f4488f131f28d74d0bdccfd0df89f84fd1f2afd9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Eric=20Garc=C3=ADa=20Cano?= Date: Thu, 9 Jul 2020 20:06:46 -0400 Subject: [PATCH 2/9] Update README.md --- README.md | 56 +++++++++++++++++++++++++++---------------------------- 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/README.md b/README.md index c8ea392..c3375c7 100644 --- a/README.md +++ b/README.md @@ -1,10 +1,10 @@ Alternative Commit Message Format (version 0.9) ============================================= -##What is it? +## What is it? This is a proposal of labels (expressions enclosed in square brackets) to be used in commit messages. The goal is to identify easily the different types of changes in a repo. -##Commit Message rules +## Commit Message rules Common layout for a commit message ``` @@ -15,7 +15,7 @@ body: used to explain the what and why of a commit, not the how. Wrap the body a footer: used to reference issue tracker IDs. ``` -####Subject desription (first line) +#### Subject desription (first line) >1. Prefix the line with an applicable label >2. Limit all the lines (subject included) to 72 characters >3. Use the imperative tone in the subject line @@ -25,45 +25,45 @@ footer: used to reference issue tracker IDs. A complete description, rules and tips can be seen in [1]. -####Main tags and meaning for source code +#### Main tags and meaning for source code **NOTE:** The first commit does not have a label, and the message always is "**Initial commit**" as convention. ->* [core] when functions, methods or classes have been added, modified or removed; method signatures or return types have changed ->* [style] when improving the format/structure of the code, without modifying the previous functionality ->* [main] when dealing with a file that is used as view, notebook or main file ->* [new] when adding a new feature (see *Rules* section) ->* [pkg] when libraries, frameworks, packages or modules are added ->* [docs] when writing documentation, formatting or comments on code; no code change ->* [test] when adding tests, refactoring tests; no production code change ->* [misc] anything not covered by the above categories, e.g. rename or move files, add configuration files, add dataset +>* **[core]** when functions, methods or classes have been added, modified or removed; method signatures or return types have changed +>* **[style]** when improving the format/structure of the code, without modifying the previous functionality +>* **[main]** when dealing with a file that is used as view, notebook or main file +>* **[new]** when adding a new feature (see *Rules* section) +>* **[pkg]** when libraries, frameworks, packages or modules are added +>* **[docs]** when writing documentation, formatting or comments on code; no code change +>* **[test]** when adding tests, refactoring tests; no production code change +>* **[misc]** anything not covered by the above categories, e.g. rename or move files, add configuration files, add dataset -####Sub-labels +#### Sub-labels Those sub-labels are used in order to provide the action that the commit does >Example: > [core>add] Subject description ->* *add* when something new has been added ->* *modify* when changes in files have been made ->* *boost* when improving performance ->* *fix* when fixing a bug (see *Rules* section) ->* *move* when files are moved between directories ->* *remove* when files or directories are deleted ->* *rename* when files or directories are renamed ->* *update* when a package's version is changed or updated(see *Rules* section) +>* **add** when something new has been added +>* **modify** when changes in files have been made +>* **boost** when improving performance +>* **fix** when fixing a bug (see *Rules* section) +>* **move** when files are moved between directories +>* **remove** when files or directories are deleted +>* **rename** when files or directories are renamed +>* **update** when a package's version is changed or updated(see *Rules* section) When fixing something on: ->* *and* (*Android*) ->* *ios* ->* *linux* ->* *macos* ->* *win* +>* **and** (*Android*) +>* **ios** +>* **linux** +>* **macos** +>* **win** Those sub-labels must be used just in combination with other label to specify a particular change related to an O.S. or a comma-separated operating systems. >Example: > [api>add|macos] Subject description -####Rules +#### Rules 1. The label [new] is only used when you are doing a merge between a change-branch and source branch. 2. The sub-label [update] must be used just when a package is updates ([pkg>update]). @@ -72,7 +72,7 @@ Those sub-labels must be used just in combination with other label to specify a >+ [api>modify+fix] the code was modified: a bug was found and WAS fixed -##REFERENCES +## REFERENCES 1. [How to Write a Git Commit Message](http://chris.beams.io/posts/git-commit/#why-not-how) Chris Beams 2. [TYPO3 CMS](http://wiki.typo3.org/CommitMessage_Format_(Git)) From 107193d5a7b034bc8ccc9f87d36833b1f342f50c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Eric=20Garc=C3=ADa=20Cano?= Date: Thu, 9 Jul 2020 20:07:41 -0400 Subject: [PATCH 3/9] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index c3375c7..07252c0 100644 --- a/README.md +++ b/README.md @@ -8,7 +8,7 @@ This is a proposal of labels (expressions enclosed in square brackets) to be use Common layout for a commit message ``` -[tag>subtag] subject description +[label>sub-label] subject description body: used to explain the what and why of a commit, not the how. Wrap the body at 72 characters in each line. From 590abdd574d3b306177b655853408e48effde711 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Eric=20Garc=C3=ADa=20Cano?= Date: Wed, 15 Jul 2020 11:34:34 -0400 Subject: [PATCH 4/9] Update README.md --- README.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/README.md b/README.md index 07252c0..b6f3f75 100644 --- a/README.md +++ b/README.md @@ -28,14 +28,14 @@ A complete description, rules and tips can be seen in [1]. #### Main tags and meaning for source code **NOTE:** The first commit does not have a label, and the message always is "**Initial commit**" as convention. ->* **[core]** when functions, methods or classes have been added, modified or removed; method signatures or return types have changed ->* **[style]** when improving the format/structure of the code, without modifying the previous functionality ->* **[main]** when dealing with a file that is used as view, notebook or main file ->* **[new]** when adding a new feature (see *Rules* section) ->* **[pkg]** when libraries, frameworks, packages or modules are added ->* **[docs]** when writing documentation, formatting or comments on code; no code change ->* **[test]** when adding tests, refactoring tests; no production code change ->* **[misc]** anything not covered by the above categories, e.g. rename or move files, add configuration files, add dataset +>* **[core]:** when functions, methods or classes have been added, modified or removed; method signatures or return types have changed +>* **[style]:** when improving the format/structure of the code, without modifying the previous functionality +>* **[main]:** when dealing with a file that is used as view, notebook or main file +>* **[new]:** when adding a new feature (see *Rules* section) +>* **[pkg]:** when libraries, frameworks, packages or modules are added +>* **[docs]:** when writing documentation, formatting or comments on code; no code change +>* **[test]:** when adding tests, refactoring tests; no production code change +>* **[misc]:** anything not covered by the above categories, e.g. rename or move files, add configuration files, add dataset #### Sub-labels Those sub-labels are used in order to provide the action that the commit does @@ -43,14 +43,14 @@ Those sub-labels are used in order to provide the action that the commit does >Example: > [core>add] Subject description ->* **add** when something new has been added ->* **modify** when changes in files have been made ->* **boost** when improving performance ->* **fix** when fixing a bug (see *Rules* section) ->* **move** when files are moved between directories ->* **remove** when files or directories are deleted ->* **rename** when files or directories are renamed ->* **update** when a package's version is changed or updated(see *Rules* section) +>* **add:** when something new has been added +>* **change:** when changes in files have been made +>* **boost:** when improving performance +>* **fix:** when fixing a bug (see *Rules* section) +>* **move:** when files are moved between directories +>* **remove:** when files or directories are deleted +>* **rename:** when files or directories are renamed +>* **update:** when a package's version is changed or updated(see *Rules* section) When fixing something on: >* **and** (*Android*) From 94110b58d01003b6b975e6b7fe8d041aeabe3dad Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Eric=20Garc=C3=ADa=20Cano?= Date: Mon, 7 Jun 2021 19:39:19 -0400 Subject: [PATCH 5/9] Update README.md --- README.md | 90 +++++++++++++++++++++++++++---------------------------- 1 file changed, 45 insertions(+), 45 deletions(-) diff --git a/README.md b/README.md index b6f3f75..84015d1 100644 --- a/README.md +++ b/README.md @@ -2,66 +2,64 @@ Alternative Commit Message Format (version 0.9) ============================================= ## What is it? -This is a proposal of labels (expressions enclosed in square brackets) to be used in commit messages. The goal is to identify easily the different types of changes in a repo. +This is a proposal of labels to be used in commit messages. The goal is to identify easily the different types of changes in a repo. ## Commit Message rules -Common layout for a commit message +Common layout for a commit message (based on [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/#summary)) + ``` -[label>sub-label] subject description +[optional scope]: -body: used to explain the what and why of a commit, not the how. Wrap the body at 72 characters in each line. +[optional body] - used to explain the what and why of a commit, not the how. Wrap the body at 72 characters in each line. -footer: used to reference issue tracker IDs. +[optional footer(s)] - used to reference issue tracker IDs ``` +The ***header*** is **mandatory** and the scope of the header is optional. + +Any line of the commit message cannot be longer 72 characters! This allows the message to be easier to read on GitHub as well as in various git tools. + +The footer should contain a closing reference to an issue if any. + +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.` + +#### Revert + +If the commit reverts a previous commit, it should begin with revert: , followed by the header of the reverted commit. In the body it should say: This reverts commit ., where the hash is the SHA of the commit being reverted. + #### Subject desription (first line) ->1. Prefix the line with an applicable label ->2. Limit all the lines (subject included) to 72 characters ->3. Use the imperative tone in the subject line ->4. Separate subject from body with a blank line ->5. Capitalize the subject line ->6. Do not end the subject line with a period +1. Prefix the line with an applicable label +2. Limit all the lines (subject included) to 72 characters +3. Use the imperative tone in the subject line +4. Separate subject from body with a blank line +5. Capitalize the subject line +6. Do not end the subject line with a period A complete description, rules and tips can be seen in [1]. #### Main tags and meaning for source code **NOTE:** The first commit does not have a label, and the message always is "**Initial commit**" as convention. ->* **[core]:** when functions, methods or classes have been added, modified or removed; method signatures or return types have changed ->* **[style]:** when improving the format/structure of the code, without modifying the previous functionality ->* **[main]:** when dealing with a file that is used as view, notebook or main file ->* **[new]:** when adding a new feature (see *Rules* section) ->* **[pkg]:** when libraries, frameworks, packages or modules are added ->* **[docs]:** when writing documentation, formatting or comments on code; no code change ->* **[test]:** when adding tests, refactoring tests; no production code change ->* **[misc]:** anything not covered by the above categories, e.g. rename or move files, add configuration files, add dataset - -#### Sub-labels -Those sub-labels are used in order to provide the action that the commit does - ->Example: -> [core>add] Subject description - ->* **add:** when something new has been added ->* **change:** when changes in files have been made ->* **boost:** when improving performance ->* **fix:** when fixing a bug (see *Rules* section) ->* **move:** when files are moved between directories ->* **remove:** when files or directories are deleted ->* **rename:** when files or directories are renamed ->* **update:** when a package's version is changed or updated(see *Rules* section) - -When fixing something on: ->* **and** (*Android*) ->* **ios** ->* **linux** ->* **macos** ->* **win** - -Those sub-labels must be used just in combination with other label to specify a particular change related to an O.S. or a comma-separated operating systems. ->Example: -> [api>add|macos] Subject description +* **core:** The most common day-to-day changes that are created while building a `feature`, that is, methods or classes that have been created, modified or removed, as well as modifications to method signatures or changes to return types . +* **feat:** Changes that introduce new feature to the codebase (this correlates with ***MINOR*** in Semantic Versioning).This is only used when you are doing a merge between a change-branch and source branch. Features may exclusively be targeted for the “master” branch. +* **fix**: A fix commit patches a bug in your codebase (this correlates with ***PATCH*** in Semantic Versioning). +* **pkg:** Used when libraries, frameworks, packages or modules are added. +* **ci:** Changes to the configuration files and scripts. +* **boost**: A code change that improves performance. +* **docs:** Used when writing documentation, formatting comments on code (no code change). +* **test:** Used when adding tests or refactoring tests (no production code change). +* **style:** Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) and do not modify previous funcionality. This type of commit neither fixes a bug nor adds a feature. +* **task:** Anything not covered by the above categories, e.g. rename or move files, add dataset, etc. +* **BREAKING CHANGE:** A commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking core change (correlating with **MAJOR** in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type. + +#### Body +Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior. + +#### Footer +The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes. + +Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then the description of the change, justification and migration notes. #### Rules 1. The label [new] is only used when you are doing a merge between a change-branch and source branch. @@ -78,6 +76,8 @@ Those sub-labels must be used just in combination with other label to specify a 2. [TYPO3 CMS](http://wiki.typo3.org/CommitMessage_Format_(Git)) 3. [Atom](https://atom.io/docs/v0.186.0/contributing) 4. [Karma](http://karma-runner.github.io/0.8/dev/git-commit-msg.html) +5. [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/#summary) +6. [Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) ------------- This document was last modified on : July 9th, 2020. From 61fc45c7fc4299f6cb013694047fde4cd0809249 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Eric=20Garc=C3=ADa=20Cano?= Date: Mon, 7 Jun 2021 19:40:23 -0400 Subject: [PATCH 6/9] Update README.md --- README.md | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/README.md b/README.md index 84015d1..f27f020 100644 --- a/README.md +++ b/README.md @@ -36,8 +36,6 @@ If the commit reverts a previous commit, it should begin with revert: , followed 5. Capitalize the subject line 6. Do not end the subject line with a period -A complete description, rules and tips can be seen in [1]. - #### Main tags and meaning for source code **NOTE:** The first commit does not have a label, and the message always is "**Initial commit**" as convention. @@ -61,15 +59,6 @@ The footer should contain any information about Breaking Changes and is also the Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then the description of the change, justification and migration notes. -#### Rules -1. The label [new] is only used when you are doing a merge between a change-branch and source branch. - -2. The sub-label [update] must be used just when a package is updates ([pkg>update]). - -3. Sometimes when you are doing modifications on your source code, it is likely to find a bug, in this case, after fixed it: ->+ [api>modify+fix] the code was modified: a bug was found and WAS fixed - - ## REFERENCES 1. [How to Write a Git Commit Message](http://chris.beams.io/posts/git-commit/#why-not-how) Chris Beams From 18f93073d4a2bcfad75aa494c72e811054a26600 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Eric=20Garc=C3=ADa=20Cano?= Date: Mon, 7 Jun 2021 19:40:55 -0400 Subject: [PATCH 7/9] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index f27f020..af4a3ec 100644 --- a/README.md +++ b/README.md @@ -49,7 +49,7 @@ If the commit reverts a previous commit, it should begin with revert: , followed * **test:** Used when adding tests or refactoring tests (no production code change). * **style:** Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) and do not modify previous funcionality. This type of commit neither fixes a bug nor adds a feature. * **task:** Anything not covered by the above categories, e.g. rename or move files, add dataset, etc. -* **BREAKING CHANGE:** A commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking core change (correlating with **MAJOR** in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type. +* **BREAKING CHANGE:** A commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking core change (correlating with ***MAJOR*** in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type. #### Body Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior. From f02bd151f7febe8e8c4eaa004c81b88117efeac6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Eric=20Garc=C3=ADa=20Cano?= Date: Mon, 7 Jun 2021 19:45:57 -0400 Subject: [PATCH 8/9] Update README.md --- README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index af4a3ec..277193f 100644 --- a/README.md +++ b/README.md @@ -47,7 +47,8 @@ If the commit reverts a previous commit, it should begin with revert: , followed * **boost**: A code change that improves performance. * **docs:** Used when writing documentation, formatting comments on code (no code change). * **test:** Used when adding tests or refactoring tests (no production code change). -* **style:** Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) and do not modify previous funcionality. This type of commit neither fixes a bug nor adds a feature. +* **style:** Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) and do not modify previous funcionality. +* **refactor:** A code change that neither fixes a bug nor adds a feature. * **task:** Anything not covered by the above categories, e.g. rename or move files, add dataset, etc. * **BREAKING CHANGE:** A commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking core change (correlating with ***MAJOR*** in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type. From 653be86fcd5d6543d7b2be8259c06869cf9058bf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Eric=20Garc=C3=ADa=20Cano?= Date: Mon, 22 Nov 2021 15:58:35 -0500 Subject: [PATCH 9/9] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 277193f..9f223eb 100644 --- a/README.md +++ b/README.md @@ -39,7 +39,7 @@ If the commit reverts a previous commit, it should begin with revert: , followed #### Main tags and meaning for source code **NOTE:** The first commit does not have a label, and the message always is "**Initial commit**" as convention. -* **core:** The most common day-to-day changes that are created while building a `feature`, that is, methods or classes that have been created, modified or removed, as well as modifications to method signatures or changes to return types . +* **core:** The most common day-to-day changes that are created while building a `feature`, that is, methods or classes that have been added (use **Add** in commit message), changed (use **change** in commit message) or removed (use **remove** in commit message), as well as changes to method signatures or to return types. * **feat:** Changes that introduce new feature to the codebase (this correlates with ***MINOR*** in Semantic Versioning).This is only used when you are doing a merge between a change-branch and source branch. Features may exclusively be targeted for the “master” branch. * **fix**: A fix commit patches a bug in your codebase (this correlates with ***PATCH*** in Semantic Versioning). * **pkg:** Used when libraries, frameworks, packages or modules are added.