Conventional Commits

Nyron uses the conventional commits specification to parse your commit history and generate meaningful changelogs.

Commit Format

The conventional commit format follows this structure:

<type>(<scope>): <message>

Components

• Type: The category of change (required)
• Scope: The area of the codebase affected (optional)
• Message: A brief description of the change (required)

Examples

feat(auth): add OAuth2 login
fix(api): resolve memory leak in endpoint
docs: update installation guide
refactor(core): simplify error handling

Supported Commit Types

Nyron recognizes and groups commits by the following types:

Changelog Grouping

Commits are organized into three main sections in the generated changelog:

Features

All commits with type feat appear under the Features section:

## Features
- **auth**: add OAuth2 login
- **dashboard**: implement real-time updates

Bug Fixes

All commits with type fix appear under Bug Fixes:

## Bug Fixes
- **api**: resolve memory leak in endpoint
- **ui**: fix button alignment issue

Chores

All other types (docs, refactor, perf, test, chore, style) are grouped under Chores:

## Chores
- **docs**: update API documentation
- **test**: add unit tests for auth module

Best Practices

Use descriptive scopes

Scopes help organize changes by area:

feat(auth): add OAuth2 login
fix(api): resolve memory leak
docs(readme): update installation steps

Write clear messages

Messages should be concise and describe what changed:

✅ Good:

feat(auth): add password reset functionality
fix(api): prevent null pointer exception in user endpoint

❌ Bad:

feat: stuff
fix: bug

Be consistent

Stick to lowercase for types and scopes, and use imperative mood for messages:

feat(core): add new feature

Not:

Feat(Core): Added new feature

Non-Conventional Commits

If a commit doesn't follow the conventional format, Nyron will:

• Still include it in the changelog
• Group it under "Other" or "Chores"
• Use the full commit message as-is

For best results, ensure all commits follow the conventional format.

GitHub Repository Setup

To maintain a clean, linear, and machine-readable git history compatible with changelog automation, your GitHub repository should follow the setup below.

Required GitHub Settings

Settings → General → Pull Requests

Settings → Branches → Branch protection rules

This is optional but strongly recommended for production repositories:

PR Title Conventions

All PR titles must follow the Conventional Commit format. This ensures changelogs are generated automatically and correctly.

type(scope): description (#PR)

Examples:

feat(api): add realtime pub/sub (#42)
fix(auth): correct token refresh (#77)
docs: clarify environment variable setup
chore: update dependencies (#88)

Issue References in Commits

You can reference GitHub issues directly in commit messages using #number format:

feat(auth): add OAuth2 login support #123
fix(api): resolve memory leak #456

Difference between PR and Issue references:

• PR references: Use parentheses (#42) - typically added automatically when squash merging
• Issue references: Use plain format #123 - manually added to reference the issue being fixed

Examples:

# Referencing an issue in a commit
git commit -m "fix(auth): resolve token expiration issue #789"

# PR title that will become the commit (when squash merged)
fix(auth): resolve token expiration issue #789 (#42)

The #number format creates clickable links in GitHub that navigate directly to the referenced issue or PR.

Next Steps

• Learn how Nyron works with these commits
• See a typical versioning workflow
• Start using the diff command to preview your commits