Messages de commit Sentry

Suivez ces conventions lors de la création de commits pour les projets Sentry.

Prérequis

Avant de valider, vérifiez toujours la branche actuelle :

git branch --show-current

Si vous êtes sur main ou master, vous DEVEZ créer une branche de fonctionnalité d'abord — sauf si l'utilisateur a explicitement demandé de valider sur main. Ne demandez pas à l'utilisateur s'il faut créer une branche ; procédez simplement à la création de la branche, puis vérifiez à nouveau la branche actuelle avant de valider. Si vous êtes toujours sur main ou master, arrêtez — ne validez pas.

Format

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

<body>

<footer>

L'en-tête est obligatoire. La portée est facultative. Toutes les lignes doivent rester sous 100 caractères.

Types de commit

Type	Objectif
`feat`	Nouvelle fonctionnalité
`fix`	Correctif de bug
`ref`	Refactorisation (pas de changement de comportement)
`perf`	Amélioration de performance
`docs`	Documentation uniquement
`test`	Ajouts ou corrections de tests
`build`	Système de build ou dépendances
`ci`	Configuration CI
`chore`	Tâches de maintenance
`style`	Formatage de code (pas de changement de logique)
`meta`	Métadonnées du dépôt
`license`	Changements de licence

Règles pour la ligne de sujet

Utilisez l'impératif, le présent : « Add feature » et non « Added feature »
Mettez en majuscule la première lettre
Pas de point à la fin
Maximum 70 caractères

Directives pour le corps

Expliquez quoi et pourquoi, pas comment
Utilisez l'impératif et le présent
Incluez la motivation du changement
Contrastez avec le comportement précédent si pertinent
Utilisez des vraies sauts de ligne dans les corps de commit ; n'incluez jamais de séquences littérales \n
N'incluez jamais de données client — noms de client/organisation, emails d'utilisateur, contenu de ticket support ou informations personnelles. Décrivez le symptôme technique, pas qui l'a rencontré, et si disponible, référencez le ticket interne (par ex. Fixes SENTRY-1234).

Hygiène de la commande de commit

Lors de la création de commits depuis la CLI, n'intégrez pas de sauts de ligne échappés comme \n dans les chaînes -m. Cela produit des caractères backslash littéraux dans le message de commit final.

Préférez l'un de ces modèles :

git commit -m "type(scope): Subject" \
  -m "Premier paragraphe avec saut de ligne réel.

Deuxième paragraphe.

Fixes GH-1234
Co-Authored-By: (le nom de l'agent et la ligne d'attribution)"

git commit

Utilisez le flux d'éditeur quand le message a besoin d'un formatage soigné.

Pied de page : Références aux issues

Référencez les issues dans le pied de page avec ces modèles :

Fixes GH-1234
Fixes #1234
Fixes SENTRY-1234
Refs LINEAR-ABC-123

Fixes ferme l'issue lors de la fusion
Refs crée un lien sans fermer

Changements générés par l'IA

Quand les changements ont été principalement générés par un agent de codage, incluez l'attribution Co-Authored-By dans le pied de page du commit. Les agents doivent utiliser leur propre identité :

Co-Authored-By: (le nom de l'agent et la ligne d'attribution)

Exemple : Co-Authored-By: Claude Sonnet 4 <noreply@example.com>

C'est le seul indicateur d'implication IA qui devrait apparaître dans les commits. N'ajoutez pas de phrases comme « Generated by AI », « Written with Claude » ou des marqueurs similaires dans le sujet, le corps ou ailleurs dans le message de commit.

Exemples

Correctif simple

fix(api): Handle null response in user endpoint

The user API could return null for deleted accounts, causing a crash
in the dashboard. Add null check before accessing user properties.

Fixes SENTRY-5678
Co-Authored-By: (le nom de l'agent et la ligne d'attribution)

Fonctionnalité avec portée

feat(alerts): Add Slack thread replies for alert updates

When an alert is updated or resolved, post a reply to the original
Slack thread instead of creating a new message. This keeps related
notifications grouped together.

Refs GH-1234

Refactorisation

ref: Extract common validation logic to shared module

Move duplicate validation code from three endpoints into a shared
validator class. No behavior change.

Changement cassant

feat(api)!: Remove deprecated v1 endpoints

Remove all v1 API endpoints that were deprecated in version 23.1.
Clients should migrate to v2 endpoints.

BREAKING CHANGE: v1 endpoints no longer available
Fixes SENTRY-9999

Format de revert

revert: feat(api): Add new endpoint

This reverts commit abc123def456.

Reason: Caused performance regression in production.

Principes

Chaque commit doit être un seul changement stable
Les commits doivent être indépendamment vérifiables
Le dépôt doit être dans un état fonctionnant après chaque commit

Références

Sentry Commit Messages