Suggested next steps
Continue this workflow
Move to a practical next or previous step without transferring your entered values.
About Git Commit Message Formatter – Conventional Commits
Format standardized Conventional Commit messages to maintain a clean git history and enable automated changelog generation.
Select standard types such as feat, fix, refactor, and chore, specify optional component scopes, and mark breaking changes.
Input is processed locally in your browser and is not sent to Navorika.
How the calculation works
Conventional format
Generates type(scope): description or type: description following standard conventions.
Breaking change indicators
Inserts ! before the colon and optionally appends a BREAKING CHANGE footer.
Whitespace normalization
Normalizes irregular spaces, trims whitespace, and strips trailing periods from the subject line.
How to use this tool
- 1Select the commit type matching your code change (feat, fix, refactor, docs, chore, etc.).
- 2Optionally specify the affected module or subsystem scope (e.g., auth, api, ui).
- 3Enter a concise, imperative description of the change.
- 4Toggle breaking change if the update alters public APIs or compatibility.
- 5Copy the formatted message or terminal command.
Understanding the result
Standardized commit formats allow automated tools like semantic-release to determine semantic version bumps automatically.
The subject line should be written in imperative mood (e.g., "add feature", not "added feature").
Keeping the header under 50 to 72 characters ensures clear rendering in git log and GitHub interfaces.
Important limitations
- The formatter does not inspect your local or remote Git repository.
- Users remain responsible for accurately describing the purpose and scope of their changes.
- Does not replace repository-specific contributing guidelines that diverge from Conventional Commits.
Explore this topic
Frequently asked questions
What is the Conventional Commits specification?
Conventional Commits is a lightweight convention on top of commit messages that provides an easy set of rules for creating an explicit commit history.
When should I use a breaking change flag?
Use breaking change (!) whenever your commit introduces a change that breaks backwards compatibility or alters existing API contracts.
Why shouldn’t the subject line end with a period?
Conventional Commits and standard Git conventions keep the subject line concise and punchy without a trailing period.
Related tools
Selected from curated relationships first, then the same subtopic and category.