From cf1d0ae8e4df75055bcab505c37feaadc8b14d1f Mon Sep 17 00:00:00 2001 From: Steven Date: Wed, 9 Jun 2021 08:45:42 -0400 Subject: [PATCH] fix: correct flexibility typo * fix: correct flexibility typo * fix: correct flexibility typo --- content/next/index.md | 2 +- content/v1.0.0/index.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/next/index.md b/content/next/index.md index 88455e3..d69abcc 100644 --- a/content/next/index.md +++ b/content/next/index.md @@ -177,7 +177,7 @@ A common workflow for this is to have your git system automatically squash commi Reverting code can be complicated: are you reverting multiple commits? if you revert a feature, should the next release instead be a patch? Conventional Commits does not make an explicit effort to define revert behavior. Instead we leave it to tooling -authors to use the flexility of _types_ and _footers_ to develop their logic for handling reverts. +authors to use the flexibility of _types_ and _footers_ to develop their logic for handling reverts. One recommendation is to use the `revert` type, and a footer that references the commit SHAs that are being reverted: diff --git a/content/v1.0.0/index.md b/content/v1.0.0/index.md index 25305f0..2222c86 100644 --- a/content/v1.0.0/index.md +++ b/content/v1.0.0/index.md @@ -178,7 +178,7 @@ A common workflow for this is to have your git system automatically squash commi Reverting code can be complicated: are you reverting multiple commits? if you revert a feature, should the next release instead be a patch? Conventional Commits does not make an explicit effort to define revert behavior. Instead we leave it to tooling -authors to use the flexility of _types_ and _footers_ to develop their logic for handling reverts. +authors to use the flexibility of _types_ and _footers_ to develop their logic for handling reverts. One recommendation is to use the `revert` type, and a footer that references the commit SHAs that are being reverted: