xsteadfastx/conventionalcommits.org
1
0
Fork 0
mirror of https://github.com/conventional-commits/conventionalcommits.org.git synced 2024-11-15 02:45:15 +01:00
Code Issues Projects Releases Wiki Activity

fix: correct flexibility typo

Browse Source 
* fix: correct flexibility typo

* fix: correct flexibility typo
This commit is contained in:
Steven 2021-06-09 08:45:42 -04:00 committed by GitHub
parent cc1e8e1c6c
commit cf1d0ae8e4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/next/index.md
View File

@ -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? 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 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: One recommendation is to use the `revert` type, and a footer that references the commit SHAs that are being reverted:

2
content/v1.0.0/index.md
View File

@ -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? 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 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: One recommendation is to use the `revert` type, and a footer that references the commit SHAs that are being reverted: