git-commit-composer

Semantic commit messages use a structured format with type (feat, fix, chore, docs, refactor, test, perf, style), a brief imperative description under 50 characters, a detailed body wrapped at 72 characters explaining what changed and why, and optional footers for issue references. This format ensures consistent, readable Git history across projects.

In semantic commits, feat indicates new functionality, fix addresses bug resolution, and chore covers maintenance tasks without affecting code. Each type signals the nature of changes, helping teams understand commit history and automate version bumping based on conventional commit standards.

Yes, semantic commit messages include optional footers where you reference GitHub issues and pull requests, maintaining traceability between code changes and their related tracking items. This creates automatic linking when commits are pushed to repositories.

The commit body provides detailed context wrapped at 72 characters, explaining the problem being solved and the rationale for the solution. This distinguishes it from the subject line, which only summarizes what changed, ensuring future developers understand both the action and its motivation.

Semantic commit conventions apply to any Git-based workflow and integrate with tools that parse commit history for automation. They're particularly valuable in projects using continuous integration, automated changelog generation, or semantic versioning where commit type and structure drive release decisions.

Non-conforming commit messages break consistency in project history and prevent automated tooling from parsing commit type and scope. Enforcing semantic format through templates or pre-commit hooks ensures all messages follow project conventions, maintaining searchable, interpretable Git history.