DevOps Tools

Conventional Commit & Changelog Generator

Build commit messages that follow the Conventional Commits spec, lint existing messages against commitlint's config-conventional rules, and turn git log output into a grouped Markdown CHANGELOG with commit links and a suggested semantic version bump.

Private by design: anything you enter is processed in your browser only. It is never uploaded to or logged on our servers. Commit messages, repository URLs and git history are processed locally and never uploaded.

Imperative mood ("add", not "added"), no trailing period. Header ≤ 72 characters recommended, 100 maximum.

Commit message 

                            

                            
    
                            
    
                                
    
                                    Shell command (bash / zsh)
                                    
    
                                        
                                        
                                    
    
                                
    
                                
    
                                
    Git joins multiple -m values with a blank line. Single quotes stop the shell from expanding $, backticks and !.
    
                            
    
                        
    
                    
    
                
    

                
                

                
                
            
    

            
            
    
                
    
    
    

                
    

            
            
    
            
    About Conventional Commits and changelogs
    
            
    
            
    Conventional Commits is a lightweight convention for commit messages: a header of the form type(scope): description, an optional body and optional footers such as Closes #123 or BREAKING CHANGE: .... Because the type is machine-readable, tools like semantic-release, release-please and commit-and-tag-version can decide the next version number and write release notes automatically, and reviewers can scan history at a glance.
    
            
    The linter applies the rules of commitlint's widely used config-conventional preset: the type must be one of the eleven standard types in lower case, the subject must not be empty, must not end with a period and must not start with a capital letter (sentence case, start case, PascalCase and UPPER CASE are rejected), and the header may be at most 100 characters. Body and footer lines are limited to 100 characters unless they contain a URL. On top of that it warns when the header is longer than 72 characters, the traditional limit that keeps git log --oneline and GitHub's commit list readable, and when the description does not look imperative ("added", "fixes").
    
            
    The changelog generator follows Semantic Versioning: any breaking change (a ! after the type or scope, or a BREAKING CHANGE: footer) means a major release, a feat means a minor release, and anything else a patch. Before 1.0.0 the public API is not considered stable, so many projects bump the minor version for breaking changes instead. Output groups entries the way conventional-changelog does (breaking changes, features, bug fixes and performance first, with other types in a collapsible block), which also fits the "keep a changelog" idea of writing release notes for humans rather than dumping raw git log.
    
            
    Since git log --pretty=format:"%h %s" only exports the subject line, breaking changes are detected from the ! marker there; a BREAKING CHANGE: footer only shows up if you export bodies too. Schedule the release job with the cron expression builder, test custom commit patterns in the regex tester, and compare two releases of a changelog with the text diff checker.
    
            
    
            
    

            
    
    
    Reference Guide
    
    
    
        
    Commit types (config-conventional) and their release impact:
    
                
    
                    
    
                        
    TypeMeaningChangelog sectionSemver impact
    
                        
                            
    featA new featureFeaturesMinor
    
                            
    fixA bug fixBug FixesPatch
    
                            
    perfA code change that improves performancePerformance ImprovementsPatch
    
                            
    revertReverts a previous commitRevertsPatch
    
                            
    docsDocumentation only changesDocumentationNone*
    
                            
    styleFormatting, white-space, semicolons; no change in meaningStylesNone*
    
                            
    refactorCode change that neither fixes a bug nor adds a featureCode RefactoringNone*
    
                            
    testAdding or correcting testsTestsNone*
    
                            
    buildBuild system or external dependencies (npm, Maven, Docker)Build SystemNone*
    
                            
    ciCI configuration files and scriptsContinuous IntegrationNone*
    
                            
    choreOther changes that do not modify source or test filesChoresNone*
    
                            
    any type with ! or BREAKING CHANGE:Incompatible API changeBreaking ChangesMajor
    
                            
                    
    
                
    
                
    * semantic-release's default rules publish no release for these types; conventional-recommended-bump (and this tool) suggest a patch.
    

                
    Message structure (Conventional Commits 1.0.0):
    
                
    <type>[optional scope][!]: <description>

[optional body]

[optional footer(s)]
    
                
      
                    
    • A blank line separates the header, body and footers.
      • 
                    
    • Footers are Token: value or Token #value; tokens use - instead of spaces (Reviewed-by, Co-authored-by), except BREAKING CHANGE, which must be upper case (BREAKING-CHANGE is a synonym).
      • 
                    
    • Types other than feat and fix are allowed by the spec; the eleven above are the commitlint defaults.
      • 
                
    

                
    Useful git commands:
    
                
    
                    
    
                        
    TaskCommand
    
                        
                            
    Subjects since the last taggit log $(git describe --tags --abbrev=0)..HEAD --pretty=format:"%h %s"
    
                            
    Between two tags, no mergesgit log v1.4.2..v1.5.0 --no-merges --pretty=format:"%h %s"
    
                            
    Find breaking changes in bodiesgit log v1.4.2..HEAD --grep="BREAKING CHANGE" --format="%h %s"
    
                            
    Lint the last commit with commitlintnpx commitlint --from HEAD~1 --to HEAD --verbose
    
                            
    Fix the last commit messagegit commit --amend (only before pushing)
    
                            
    Create an annotated release taggit tag -a v1.5.0 -m "v1.5.0"
    
                            
                    
    
                
    
    
    

            
    Example input
    
        
    a1b2c3d feat(auth)!: drop support for session tokens in query strings
e4f5a6b feat(api): add cursor-based pagination to orders endpoint (#142)
0c9d8e7 fix(api): return 404 instead of 500 for unknown order ids (#145)
5a6b7c8 perf(db): add index on orders.created_at
9d8c7b6 docs: document pagination parameters
    
        
    This sample loads automatically when you open the tool. Use Load Sample to bring it back.
    
    
    

        
    
    
    


    
    
    
        
    
    
    

        
    

    

            
            
    
                
    
        
    Frequently Asked Questions
    
        
    
                            
    
                    
                    
    
                        
    A convention for commit messages in the form type(scope): description, for example feat(auth): add login with Google. The structure lets tools generate changelogs and pick the next semantic version automatically.
    
                    
    
                
    
                            
    
                    
                    
    
                        
    A breaking change bumps the major version, a feat bumps the minor version, and fixes and other types bump the patch version, following Semantic Versioning.
    
                    
    
                
    
                            
    
                    
                    
    
                        
    Add ! after the type or scope, such as feat(api)!: remove v1 endpoints, or add a BREAKING CHANGE: footer that explains what changed.
    
                    
    
                
    
                    
    
    
    

    
        
            
    

            
            
    
                
    
        
    
            
    Related Tools
    
            
                All DevOps Tools →
            
        
    
        
    
                            
                    
    
                        
                            
                        
                    
    
                    
    
                        
    
                            Web Server Config Generator
                        
    
                        
    
                            Generate Nginx server blocks and Apache .htaccess rules for...
                        
    
                    
    
                    
                            
                    
    
                        
                            
                        
                    
    
                    
    
                        
    
                            CSP Header Builder
                        
    
                        
    
                            Build a Content-Security-Policy header directive by directiv...
                        
    
                    
    
                    
                            
                    
    
                        
                            
                        
                    
    
                    
    
                        
    
                            SPF, DKIM & DMARC Record Generator
                        
    
                        
    
                            Generate and check SPF, DKIM and DMARC DNS TXT records for e...
                        
    
                    
    
                    
                            
                    
    
                        
                            
                        
                    
    
                    
    
                        
    
                            SOAP Message Viewer & Request Builder
                        
    
                        
    
                            Format and inspect SOAP 1.1 and 1.2 envelopes, read headers,...
                        
    
                    
    
                    
                            
                    
    
                        
                            
                        
                    
    
                    
    
                        
    
                            XPath & CSS Selector Tester
                        
    
                        
    
                            Test XPath expressions and CSS selectors against your HTML o...
                        
    
                    
    
                    
                            
                    
    
                        
                            
                        
                    
    
                    
    
                        
    
                            Gherkin Formatter & Validator
                        
    
                        
    
                            Format and validate Gherkin feature files for Cucumber, Spec...