jimeh/common-flow
1
0
Fork 0
mirror of https://github.com/jimeh/common-flow.git synced 2026-02-19 01:16:40 +00:00
Code Issues Packages Projects Releases Wiki Activity

feat(commits): update commit message guidelines to use conventional commits

Browse Source 
Update guidelines for commit messages to recommend Conventional
Commits specification. Clarify best practices for version bumps,
breaking changes, and semantic versioning alignment. Emphasize
benefits of structured commit messages for changelog generation
and automated version determination.
This commit is contained in:
Jim Myhrberg
2026-01-10 06:59:35 +00:00
parent 12daa305b3
commit 06d46881da
1 changed files with 24 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
common-flow.md
View File

@@ -155,10 +155,10 @@ interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
5. If you are not using a release branch, then the release tag, and if 5. If you are not using a release branch, then the release tag, and if
relevant the version bump commit, MUST be created directly on the main relevant the version bump commit, MUST be created directly on the main
branch. branch.
6. The version bump commit SHOULD have a commit message title of "Bump 6. The version bump commit SHOULD have a commit message following the
version to VERSION". For example, if the new version string is "2.11.4", Conventional Commits format. For example "chore(release): 2.11.4" or
the first line of the commit message SHOULD read: "Bump version to "chore: bump version to 2.11.4". Alternatively a simple "Bump version to
2.11.4" 2.11.4" format is acceptable.
7. It is RECOMMENDED that release tags are lightweight tags, but you can 7. It is RECOMMENDED that release tags are lightweight tags, but you can
OPTIONALLY use annotated tags if you want to include changelog OPTIONALLY use annotated tags if you want to include changelog
information in the release tag itself. information in the release tag itself.
@@ -166,6 +166,16 @@ interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
SHOULD read "Release VERSION". For example for version "2.11.4" the first SHOULD read "Release VERSION". For example for version "2.11.4" the first
line of the tag annotation SHOULD read "Release 2.11.4". The second line line of the tag annotation SHOULD read "Release 2.11.4". The second line
MUST be blank, and the changelog MUST start on the third line. MUST be blank, and the changelog MUST start on the third line.
9. When using Conventional Commits, breaking changes MUST be indicated
either by appending "!" after the type/scope (e.g. "feat!:" or
"feat(api)!:"), or by including a "BREAKING CHANGE:" footer in the commit
message. Breaking changes correspond to a MAJOR version bump in Semantic
Versioning.
10. When using Conventional Commits along with Semantic Versioning, commits
of type "fix" correspond to PATCH releases, commits of type "feat"
correspond to MINOR releases, and commits with breaking changes
correspond to MAJOR releases. This alignment enables automated version
determination and changelog generation.
7. Short-Term Release Branches 7. Short-Term Release Branches
1. Any branch that has a name starting with "release-" SHOULD be referred to 1. Any branch that has a name starting with "release-" SHOULD be referred to
as a "release branch". as a "release branch".
@@ -227,9 +237,12 @@ interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
merge commit itself. Effectively creating a new commit that reverses all merge commit itself. Effectively creating a new commit that reverses all
the relevant changes. the relevant changes.
10. Git Best Practices 10. Git Best Practices
1. All commit messages SHOULD follow the Commit Guidelines and format from 1. It is RECOMMENDED that all commit messages follow the Conventional
the official git Commits specification (<https://www.conventionalcommits.org/>). This
documentation: provides a structured format that integrates well with Semantic
Versioning, and enables automated changelog generation. At minimum,
commit messages SHOULD follow the Commit Guidelines from the official
git documentation:
<https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines> <https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines>
2. You SHOULD never blindly commit all changes with "git commit -a". It is 2. You SHOULD never blindly commit all changes with "git commit -a". It is
RECOMMENDED you use "git add -i" or "git add -p" to add individual RECOMMENDED you use "git add -i" or "git add -p" to add individual
@@ -249,6 +262,10 @@ interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
commits, allows one to revert a merge by reverting a single merge commit, commits, allows one to revert a merge by reverting a single merge commit,
and creates a merge commit to mark the integration of the branch with and creates a merge commit to mark the integration of the branch with
main. main.
7. When using Conventional Commits, it is RECOMMENDED to use tooling to
automatically generate changelogs from commit messages. This pairs well
with the release process and ensures changelogs are consistent and
complete.
FAQ FAQ
--- ---