commit

작성자: sentry

Sentry 관용적 커밋 형식을 적용하며, 적절한 유형, 범위 및 이슈 참조를 포함합니다. main 또는 master 브랜치에 커밋하기 전에 기능 브랜치 생성을 요구하며, create-branch 스킬을 사용하여 브랜치 워크플로를 관리합니다. 12가지 커밋 유형(feat, fix, ref, perf, docs, test, build, ci, chore, style, meta, license)을 지원하며, 명확한 제목 줄 규칙과 이슈 참조를 위한 바닥글 패턴을 포함합니다. AI 생성 변경 사항에 대한 Co-Authored-By 속성을 포함하고, 명시적인 주요 변경 사항을 처리합니다.

npx skills add https://github.com/getsentry/skills --skill commit

ZIP 다운로드 GitHub

993

이 스킬 사용해 보기스폰서

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"