This article may incorporate text from a large language model, which is prohibited in Wikipedia articles. It may include hallucinated information, copyright violations, claims not verified in cited sources, original research, or fictitious references. Any such material should be removed. (January 2026) (Learn how and when to remove this message)

Conventional Commits Specification (CCS) is the specification formalizing the categorization of commits in version control systems. This classification system distinguishes code changes based on their purpose—such as features, bug fixes, or documentation updates—to facilitate automated processes like changelog generation and semantic versioning.^{[note 1]}

Tracking codebase history relies on the descriptions attached to version control updates and is made easier by standardizing these comments. E. B. Swanson's 1976 taxonomy separated software maintenance into adaptive, corrective, and perfective tasks, but the practicalities dictated more granular classification.^{[note 2]}

The Conventional Commits Specification (CCS) is a widely adopted standard that mandates strict formatting for version control descriptions:

<type>[optional scope]: <description>
[optional body]
[optional footer(s)]

The required <type> element categorizes the commit into one of ten specific groups, ensuring the change log can be parsed programmatically.^{[note 3]} An optional footer is also commonly used to flag backwards-incompatible code changes via a BREAKING CHANGE identifier, which external scripts and developers rely on to manage semantic version bumps safely.^{[note 4]}

The definitions of the ten categories were originally linked to the Angular but stricter outlines to prevent categorical overlap were eventually proposed:^{[note 5]}

• Feature (feat): Code additions that implement new capabilities, whether intended for end-users or internal development.
• Fix (fix): Patches designed to resolve defects and errors in the software.
• Performance (perf): Adjustments made to optimize resource usage, like speeding up execution or lowering memory footprint, without altering the program's primary function.
• Style (style): Aesthetic or formatting alterations (such as correcting indentation, fixing linting warnings, or renaming variables) that do not influence execution.
• Refactor (refactor): Modifications that reorganize existing code to boost overall maintainability, strictly excluding any changes that qualify merely as stylistic or performance-based.
• Documentation (docs): Updates applied to textual resources, including comments within the code, README files, and typo corrections.
• Test (test): The creation or revision of automated testing scripts.
• Continuous Integration (ci): Adjustments to continuous integration and deployment pipelines or scripts (e.g., GitHub Actions setups).
• Build (build): Alterations to external dependencies, compilation configurations, and project build tools.
• Chore (chore): Any remaining development tasks that do not align with the specific labels above.

This system splits modifications by purpose (the intent behind a change) and object (the target file or framework being changed). When a change bridges multiple concepts, the underlying intent takes priority. For instance, rewriting a testing script to run more efficiently falls under "refactor" rather than "test".^{[note 6]}

The standard's footprint is steadily expanding across open-source ecosystems. In 2025, an academic review of several thousand highly-rated GitHub repositories noted that in 2023 over a hundred projects had formally integrated the specification into their workflows.^{[note 7]} Integration generally takes one of two forms:

• Document declaration: Explicitly mandating the rules within contributor documentation.
• Integrated automation: Actively enforcing compliance through CI/CD hooks or formatting software like commitlint.^{[note 8]}

The practice is deeply entrenched within the NPM registry. A review of 381 top-tier NPM libraries revealed that nearly 95% housed commits formatted via CCS guidelines. Moreover, over half of these libraries maintained an 80% or higher compliance rate throughout their commit history, illustrating robust enforcement in JavaScript settings.^{[note 9]} Adherence is also growing informally; roughly one in ten commits in non-mandating projects voluntarily applied the formatting in 2023.^{[note 10]}

Contributors encounter periodic friction when categorizing their work manually. A review of developer sentiment across platforms like Stack Overflow and GitHub highlighted four primary hurdles:^{[note 11]}

• Type confusion: Representing the majority of reported problems, users frequently struggle to select the correct label. Ambiguities often arise between differentiating structural improvements, optimizations, and aesthetic changes, or deciding between a new capability and a maintenance task.
• Type aliases: Contributors sometimes ask to substitute official terms with their preferred vocabulary (for instance, swapping "fix" for "patch").
• Changing types: Users occasionally propose expanding the vocabulary with new labels like "security" or eliminating existing ones.
• Lack of definitions: Because the official standard relies heavily on the somewhat broad guidelines of the Angular framework, programmers frequently advocate for a stricter, more absolute glossary of terms.^{[note 12]}

To ease the burden of manual categorization, researchers have investigated machine learning solutions. Older BERT algorithms excel at the traditional three-part maintenance taxonomy but face difficulties mapping commits to the ten specific CCS labels.^{[note 13]}

Conversely, fine-tuned implementations of code-specific Large Language Models (such as CodeLlama) show significant promise, yielding higher accuracy and macro F1 scores than baseline architectures or proprietary systems like GPT-4.^{[note 14]} However, distinguishing the "refactor" and "chore" labels continues to be a machine learning challenge because their scopes are heavily context-dependent and residual.^{[note 15]}

• Zeng, Qunhong; Zhang, Yuxia; Qiu, Zhiqing; Liu, Hui (2025). A First Look at Conventional Commits Classification (PDF). 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). Ottawa, ON, Canada: IEEE. pp. 2277–2289. doi:10.1109/ICSE55347.2025.00011.
• Kong, Dezhen; Liu, Jiakun; Bao, Lingfeng; Lo, David (2025). "Toward Better Comprehension of Breaking Changes in the NPM Ecosystem". ACM Transactions on Software Engineering and Methodology. 34 (4). New York, NY, USA: Association for Computing Machinery: 111:1–111:23. doi:10.1145/3702991.

• "Conventional Commits 1.0.0". Conventional Commits. Retrieved 31 December 2025.