Skip to content

commit.instructions.md

Latest commit

 

History

History
62 lines (51 loc) · 2.17 KB

commit.instructions.md

File metadata and controls

62 lines (51 loc) · 2.17 KB

Commit Message Guidelines

Follow these rules for all commit messages to ensure clarity and consistency.

Commit Message Format

<type>[optional scope]: <subject>
<BLANK LINE>
[optional body]
  • type: One of feat, fix, docs, style, refactor, test, perf, build, ci, chore, revert
  • scope: (Optional) A noun describing the section affected (e.g., api, ui, auth)
  • subject: Short, imperative summary (max 50 characters, no period)
  • body: (Optional) Detailed explanation, reasoning, or context

Examples

feat(api): Add user login endpoint
fix(ui): Correct button alignment
docs(README): update usage section for clarity
style: format codebase using Prettier
refactor(auth): simplify token handling logic and improve error handling

# Explanations:
# - Used lowercase for commit types/scopes for Conventional Commits consistency.
# - Made descriptions more specific and actionable.
# - Added "improve error handling" to encourage robust refactoring.
# - Used imperative mood for clarity and best practices.
test(api): Add tests for login
perf: Optimize query performance
build: Update dependencies
ci: Add GitHub Actions workflow
chore: Remove unused files
revert: Revert "feat(api): Add user login endpoint"

Best Practices

  • Use imperative mood in the subject (e.g., "Add", not "Added" or "Adds")
  • Start subject with a capital letter
  • Do not end subject with a period
  • Limit subject to 50 characters for readability
  • Leave a blank line between subject and body
  • Use the body for:
    • Explaining the motivation and context
    • Listing multiple changes as bullet points
    • Referencing related issues or PRs (e.g., "Closes #123")
  • Ensure messages are descriptive and actionable
  • For breaking changes, start the body with BREAKING CHANGE:
  • Only mention files that are directly affected by the change

Error Handling & Edge Cases

  • If reverting a commit, use the revert: type and reference the original commit
  • For multi-part changes, consider splitting into focused commits
  • Avoid ambiguous types or scopes; be specific

Atomic Commits

  • Each commit should represent a single logical change
  • Avoid large commits that mix multiple changes