Conventional Commits & Semantic Releases Markdown Table Template
Conventional Commit specifications mapping commit type prefixes to SemVer release impacts, changelog categories, and example formats.
Interactive Template Customizer
Edit cells, add rows, or sort — changes update the markdown liveColumn Architecture & Alignment Specification
Carefully chosen column alignments ensure optimal visual scannability across desktop and mobile screens:
| Column Header | Alignment | Delimiter Syntax | Design Rationale |
|---|---|---|---|
| Commit Type | left | :--- | Standard left-aligned readable text & descriptions |
| Description / Purpose | left | :--- | Standard left-aligned readable text & descriptions |
| SemVer Impact | center | :---: | Centers compact status symbols, flags, or tags |
| Changelog Section | left | :--- | Standard left-aligned readable text & descriptions |
| Commit Message Example | left | :--- | Standard left-aligned readable text & descriptions |
Pro Tips for Conventional Commits & Semantic Releases
- Format type prefixes in inline code (`feat:`, `fix:`, `chore:`).
- Center-align SemVer Impact column (MAJOR, MINOR, PATCH).
- Bold breaking change indicator (`feat!:`) to highlight major version bumps.
How to Deploy This Table Across Platforms
Paste raw Markdown into README.md. Leave one blank newline above and below for GFM compliance.
Paste directly into Live Preview mode. Use wikilinks ([[Note]]) inside cells for bidirectional linking.
Press Enter to make a fresh empty line block, then paste. Notion auto-transforms it into a native Simple Table block.
Standard GFM tables work out of the box in modern MDX engines. You can style them via custom CSS selectors.
Raw GFM Code
| Commit Type | Description / Purpose | SemVer Impact | Changelog Section | Commit Message Example |
| :--------------- | :---------------------------------------------------------- | :-----------: | :------------------- | :----------------------------------------------------- |
| `feat` | A brand new user-facing feature or capability | **MINOR** | Features | `feat(editor): add multi-cursor keyboard shortcuts` |
| `fix` | A bugfix resolving an existing issue | **PATCH** | Bug Fixes | `fix(parser): escape literal pipes inside inline code` |
| `feat!` / `fix!` | Any change introducing a breaking API modification | **MAJOR** | ⚠️ Breaking Changes | `feat(api)!: remove deprecated v1 endpoint` |
| `docs` | Documentation only changes (README, guides, comments) | None | Documentation | `docs(readme): add docker port configuration table` |
| `perf` | Code change improving algorithmic performance or latency | **PATCH** | Performance | `perf(engine): optimize AST matrix transposition` |
| `refactor` | Code restructuring without changing behavior or fixing bugs | None | Internal | `refactor(utils): extract delimiter sniffing logic` |
| `chore` | Build process, package updates, or tooling configuration | None | Chores | `chore(deps): bump next from 15.0 to 15.1` |Standard padded style with boundary pipes matching GitHub GFM parser specifications.
Platform Support
Syntax Formatting Rules
- Pipe Escaping: Use
\|for text with pipe symbols. - Multi-line Cells: Use
<br>for line breaks. - Monospace Text: Wrap variables or code in backticks (
`key`). - Empty Values: Use
—instead of leaving cells empty.
More Developer Markdown Templates
Browse all 50 templatesREST & GraphQL API Parameters
Document REST endpoints, GraphQL query fields, request payload types, requirements, and default fallback values.
Environment Variables (.env) Matrix
Document required and optional environment keys, secret classifications, types, and staging vs production defaults.
CLI Options & Arguments Reference
Reference table for command-line tool options, shorthand aliases, data types, environment overrides, and descriptions.
Frequently Asked Questions About Conventional Commits & Semantic Releases
How should I format parameters, flags, or keys in this Conventional Commits & Semantic Releases table?
Wrap variable names in the "Commit Type" column in backticks (e.g., `feat`). This enforces monospace rendering, prevents underscores from italicizing surrounding text, and improves readability across GitHub and developer documentation sites.
Where in my repository or project documentation should I place this Conventional Commits & Semantic Releases table?
This template is specifically designed for contributing.md instructions, pr templates, commitlint configuration guides. Place it inside your project's README.md, technical wiki, or developer portal. Always leave at least one blank newline before and after the table to ensure the GFM parser detects it properly.
Why is the "Commit Type" column styled with left alignment?
The "Commit Type" column functions as the primary key of this table. Setting it to left alignment establishes an anchor along the left reading margin, making it effortless for developers to scan down the list.
How do I add line breaks inside a single cell of this Conventional Commits & Semantic Releases table?
Standard Markdown table rows cannot contain literal carriage returns. To create a multi-line list inside a cell, insert HTML <br> tags (e.g. "Item 1<br>Item 2<br>Item 3"). This keeps the entire entry in a single clean row without breaking column alignments.
How do I handle optional or missing values in Conventional Commits & Semantic Releases?
Never leave table cells completely empty, as some strict Markdown parsers may collapse empty pipes. Instead, insert an em-dash ("—"), "N/A", or "None" to explicitly indicate that a value is not applicable.
Can I export this Conventional Commits & Semantic Releases table into CSV, Excel, or HTML?
Yes. In the interactive toolkit above, you can edit your data and use our integrated export tools to convert this table directly into CSV, JSON, HTML <table>, or LaTeX with a single click.