Commit

Commit

ALWAYS use this skill when committing code changes — never commit directly without it. Creates commits following Sentry conventions with proper

Category: development Source: getsentry/skills

What Is This?

Overview

The Commit skill is a structured workflow tool designed for developers working within Sentry projects. It enforces a consistent commit message format based on conventional commit standards, ensuring that every code change is documented with clarity, traceability, and proper issue references. Rather than leaving commit message quality to individual discretion, this skill standardizes the process across teams and contributors.

At its core, the skill requires developers to always use it when committing code changes. Direct commits without following the defined conventions are explicitly discouraged. This approach reduces noise in version history, makes automated changelog generation more reliable, and improves the overall readability of a project's git log over time.

The skill integrates branch awareness into the commit workflow. Before creating a commit, developers are prompted to verify the current branch using a simple command, which prevents accidental commits to protected or incorrect branches. This small but important step reduces costly mistakes in fast-moving development environments.

Who Should Use This

  • Backend and frontend engineers contributing to Sentry or Sentry-adjacent repositories
  • Open source contributors submitting pull requests to the getsentry organization
  • Engineering leads who want to enforce consistent commit hygiene across their teams
  • DevOps and release engineers who rely on structured commit messages for automated versioning
  • New team members onboarding to Sentry projects who need clear guidance on contribution standards
  • Code reviewers who benefit from well-formatted commit histories during pull request evaluation

Why Use It?

Problems It Solves

  • Inconsistent commit messages that make it difficult to understand the intent or scope of a change when reviewing history
  • Missing issue references that break traceability between code changes and the tickets or bugs they address
  • Accidental commits to the wrong branch due to skipping pre-commit branch verification
  • Poorly structured changelogs caused by commit messages that do not follow a parseable conventional format
  • Onboarding friction for new contributors who are unsure how to format commits correctly for Sentry projects

Core Highlights

  • Enforces conventional commit format for all code changes
  • Requires branch verification before committing using git branch --show-current
  • Supports proper issue reference linking within commit messages
  • Reduces ambiguity in pull request reviews and code history
  • Aligns with widely adopted open source commit standards
  • Prevents direct commits that bypass the defined workflow
  • Improves compatibility with automated release and changelog tooling
  • Applicable to any commit, git commit, save changes, or commit message task

How to Use It?

Basic Usage

Before making any commit, verify the active branch to confirm you are working in the correct context:

git branch --show-current

Once confirmed, structure your commit message using the conventional commit format:

<type>(<scope>): <short description>

[optional body]

Fixes #<issue-number>

A complete example looks like this:

fix(auth): handle token expiry during session refresh

Updated the session handler to catch expired token errors and
trigger a re-authentication flow instead of silently failing.

Fixes #4821

Specific Scenarios

Scenario 1: Bug Fix with Issue Reference A developer resolves a reported authentication bug. After verifying the branch, they write a commit using the fix type, include the affected scope, and append the issue number using the Fixes keyword to close the ticket automatically upon merge.

Scenario 2: New Feature Addition A developer adds a new API endpoint. They use the feat type to signal a new capability, include a concise description, and optionally describe the motivation in the commit body for reviewers.

Real-World Examples

  • feat(api): add rate limiting to ingest endpoint with a body explaining the threshold values chosen
  • chore(deps): upgrade sentry-sdk to 1.40.0 referencing the dependency update ticket
  • refactor(events): simplify event normalization pipeline with notes on performance improvements observed

When to Use It?

Use Cases

  • Committing a bug fix that resolves a tracked issue
  • Adding a new feature to a Sentry project
  • Updating dependencies or configuration files
  • Refactoring existing code without changing external behavior
  • Writing or updating documentation within the repository
  • Reverting a previous commit that introduced a regression
  • Performing routine maintenance or cleanup tasks

Important Notes

Requirements

  • Git must be installed and configured with appropriate user credentials
  • The repository must follow Sentry project conventions for this skill to apply correctly
  • Developers must have access to the relevant issue tracker to include accurate issue references