From f1ad4d19128dad5e3fb12f1c11f2bb612bf163d4 Mon Sep 17 00:00:00 2001 From: Mario Erazo Date: Mon, 14 Jun 2021 12:02:25 +0200 Subject: [PATCH 1/4] Add convential commits item --- radar/2021-01-01/conventionalcommits.md | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 radar/2021-01-01/conventionalcommits.md diff --git a/radar/2021-01-01/conventionalcommits.md b/radar/2021-01-01/conventionalcommits.md new file mode 100644 index 0000000..9109599 --- /dev/null +++ b/radar/2021-01-01/conventionalcommits.md @@ -0,0 +1,9 @@ +--- +title: "Conventional Commits" +ring: trial +quadrant: methods-and-patterns +featured: false +--- +The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an small set of rules for writing commit messages and therefore creating an explicit commit history. The convention dovetails with [SemVer](https://semver.org/), by describing the features, fixes, and breaking changes made in commit messages. The specification contains only 16 items that are easy to follow. The predefined structure allows everyone in the team to get a better overview of what the commit messages relates to and what part of the code a change has to do with. Some of the benefits of using this specifications include: the ability to automatically generate changelogs, the ability to determine a semantic version bump (based on the types of commits landed) and being able to communicate the nature of changes to teammates and stakeholders. + +We use conventional commits in the team with the help of a git template. The template contains a guide of elements that are required in the specification plus some information about project specific items that should also be part of a commit, such as a ticket number. From 78f06aae7519ca6ba68d048c31d833230fc7975b Mon Sep 17 00:00:00 2001 From: Brian Hoffmann Date: Mon, 14 Jun 2021 15:20:17 +0200 Subject: [PATCH 2/4] Grammar --- radar/2021-01-01/conventionalcommits.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/radar/2021-01-01/conventionalcommits.md b/radar/2021-01-01/conventionalcommits.md index 9109599..ca040b7 100644 --- a/radar/2021-01-01/conventionalcommits.md +++ b/radar/2021-01-01/conventionalcommits.md @@ -4,6 +4,6 @@ ring: trial quadrant: methods-and-patterns featured: false --- -The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an small set of rules for writing commit messages and therefore creating an explicit commit history. The convention dovetails with [SemVer](https://semver.org/), by describing the features, fixes, and breaking changes made in commit messages. The specification contains only 16 items that are easy to follow. The predefined structure allows everyone in the team to get a better overview of what the commit messages relates to and what part of the code a change has to do with. Some of the benefits of using this specifications include: the ability to automatically generate changelogs, the ability to determine a semantic version bump (based on the types of commits landed) and being able to communicate the nature of changes to teammates and stakeholders. +The Conventional Commits specification is a lightweight convention on top of commit messages. It provides a small set of rules for writing commit messages and therefore creating an explicit commit history. The convention dovetails with [SemVer](https://semver.org/), by describing the features, fixes, and breaking changes made in commit messages. The specification contains only 16 items that are easy to follow. The predefined structure allows everyone in the team to get a better overview of what the commit messages relates to and what part of the code a change has to do with. Some benefits of using these specifications include: the ability to automatically generate changelogs, the ability to determine a semantic version bump (based on the types of commits landed) and being able to communicate the nature of changes to teammates and stakeholders. We use conventional commits in the team with the help of a git template. The template contains a guide of elements that are required in the specification plus some information about project specific items that should also be part of a commit, such as a ticket number. From 9ac1c350a495705747c1ae3b86cc6e5d573628b5 Mon Sep 17 00:00:00 2001 From: Brian Hoffmann Date: Mon, 14 Jun 2021 15:22:22 +0200 Subject: [PATCH 3/4] Link semver internally --- radar/2021-01-01/conventionalcommits.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/radar/2021-01-01/conventionalcommits.md b/radar/2021-01-01/conventionalcommits.md index ca040b7..facc622 100644 --- a/radar/2021-01-01/conventionalcommits.md +++ b/radar/2021-01-01/conventionalcommits.md @@ -4,6 +4,6 @@ ring: trial quadrant: methods-and-patterns featured: false --- -The Conventional Commits specification is a lightweight convention on top of commit messages. It provides a small set of rules for writing commit messages and therefore creating an explicit commit history. The convention dovetails with [SemVer](https://semver.org/), by describing the features, fixes, and breaking changes made in commit messages. The specification contains only 16 items that are easy to follow. The predefined structure allows everyone in the team to get a better overview of what the commit messages relates to and what part of the code a change has to do with. Some benefits of using these specifications include: the ability to automatically generate changelogs, the ability to determine a semantic version bump (based on the types of commits landed) and being able to communicate the nature of changes to teammates and stakeholders. +The Conventional Commits specification is a lightweight convention on top of commit messages. It provides a small set of rules for writing commit messages and therefore creating an explicit commit history. The convention dovetails with [SemVer](/methods-and-patterns/semver2.html), by describing the features, fixes, and breaking changes made in commit messages. The specification contains only 16 items that are easy to follow. The predefined structure allows everyone in the team to get a better overview of what the commit messages relates to and what part of the code a change has to do with. Some benefits of using these specifications include: the ability to automatically generate changelogs, the ability to determine a semantic version bump (based on the types of commits landed) and being able to communicate the nature of changes to teammates and stakeholders. We use conventional commits in the team with the help of a git template. The template contains a guide of elements that are required in the specification plus some information about project specific items that should also be part of a commit, such as a ticket number. From 43a6cab4029dea4a5c9c45793770f614130cdc3d Mon Sep 17 00:00:00 2001 From: Brian Hoffmann Date: Mon, 14 Jun 2021 15:25:32 +0200 Subject: [PATCH 4/4] feature --- radar/2021-01-01/conventionalcommits.md | 1 - 1 file changed, 1 deletion(-) diff --git a/radar/2021-01-01/conventionalcommits.md b/radar/2021-01-01/conventionalcommits.md index facc622..f0aca6f 100644 --- a/radar/2021-01-01/conventionalcommits.md +++ b/radar/2021-01-01/conventionalcommits.md @@ -2,7 +2,6 @@ title: "Conventional Commits" ring: trial quadrant: methods-and-patterns -featured: false --- The Conventional Commits specification is a lightweight convention on top of commit messages. It provides a small set of rules for writing commit messages and therefore creating an explicit commit history. The convention dovetails with [SemVer](/methods-and-patterns/semver2.html), by describing the features, fixes, and breaking changes made in commit messages. The specification contains only 16 items that are easy to follow. The predefined structure allows everyone in the team to get a better overview of what the commit messages relates to and what part of the code a change has to do with. Some benefits of using these specifications include: the ability to automatically generate changelogs, the ability to determine a semantic version bump (based on the types of commits landed) and being able to communicate the nature of changes to teammates and stakeholders.