commit

Sentry Commit Messages

Before Committing

git branch --show-current

If the branch is main or master, create a feature branch unless the user explicitly requested a direct commit. Re-check the branch and stop if it is still main or master.

Commit one coherent, independently reviewable change at a time.

Message Rules

Use:

<type>(<scope>): <subject>

<optional body>

<optional footer>

• Scope is optional. Add ! before : for a breaking change.
• Write the subject in imperative, present tense; capitalize it, omit the trailing period, and keep it at 70 characters or fewer.
• Keep every line under 100 characters.
• Use the body only when useful. Explain what changed and why, including previous behavior or motivation when it helps.
• Never include customer or organization names, user emails, support ticket contents, secrets, or PII. Describe the technical symptom instead.

Allowed types: feat, fix, ref, perf, docs, test, build, ci, chore, style, meta, license, and revert.

Use ref for refactoring without behavior changes, style for formatting without logic changes, and meta for repository metadata.

Footers

• Fixes <issue> closes an issue when merged.
• Refs <issue> links an issue without closing it.
• For breaking changes, add BREAKING CHANGE: <impact>.

Creating the Commit

Use separate -m arguments for paragraphs and footers. Never put literal \n sequences in a commit message or open an interactive editor.

git commit -m "fix(api): Handle null response in user endpoint" \
  -m "Return 404 when the user API finds a deleted account." \
  -m "Fixes SENTRY-5678"