writing-commit-messages

Conventional commit messages follow a structured format: a subject line with an optional kind (feat, fix, docs, style, refactor, test, chore) in imperative mood, under 72 characters, followed by a blank line and a body describing the change. This format makes commit history readable and enables automated tooling.

Use imperative mood, start with an allowed kind (feat, fix, docs, style, refactor, test, chore), keep it under 72 characters, and avoid duplicating the diff. Example: 'feat: add user login validation' communicates the change clearly and concisely.

Yes. Append a Co-Authored-By trailer to the commit message body to attribute contributions. This is useful when multiple people collaborate on a commit and need proper credit in the project history.

The body uses semantic line breaks, explains the rationale and context for the change without repeating the diff, and maintains readability. Avoid empty bodies—if no body is needed, write a clear subject line only.

Apply the same conventional commit structure: concise subject line with kind and imperative mood, followed by a body that explains the changes. This ensures consistency across commits and pull requests in your project.

Use 'feat' for new features, 'fix' for bug fixes, 'docs' for documentation changes, 'style' for formatting, 'refactor' for code restructuring, 'test' for test additions, and 'chore' for maintenance tasks. The kind categorizes the type of change for clarity and tooling.