コミットとPRの規約
PRのタイトルと初期本文は、スカッシュマージ時にそのままコミットメッセージとして使用されるものとして扱います。
コミットメッセージ
- まずリポジトリの指示を読みます。スコープはリポジトリローカルの
commit-scopeスキルを使って導出します。利用できない場合は、明示的なリポジトリルールに従うか、スコープを省略します（発明はしません）。 - Conventional Commits に従います:
<type>[optional scope][!]: <description> - 50文字を目標とし、結果としての動作を説明します。目標達成のためにリポジトリ必須のスコープを削らないでください。必須スコープがあるために50文字に収まらない場合は、残りの説明を可能な限り簡潔に保ちます。
- 件名、本文、フッターは空行で区切ります。
- スタンドアロンコミットの場合、本文の行は72文字で折り返します。なぜ変更が必要だったか、どのように解決したか、および重要な副作用を説明します。
- 既存のチケットキーやリンクは件名ではなくフッターに配置します:
Issue: PROJECT-123。課題が存在する場合はリポジトリ固有のフッター形式に従います。課題が存在しない場合はフッターを省略し、Issue: N/Aのようなものを捏造しないでください。 - 該当するConventional Commitsのフッターと、コラボレーター向けの
Co-authored-by: 名前 <メール>トレーラーを追加します。 - タイプは影響を受ける表面領域で選択し、変更が欠陥を修正するかどうかでは選択しません。
- CI、ワークフロー、自動化の変更（それらの自動化への修正を含む）には
ciを使用します。 - 製品またはランタイムのバグ、および外部に公開されたAPI境界に対する非機能変更には
fixを使用します。 - 機能には
feat、ビルドまたは依存関係にはbuild、非製品ツールまたは設定にはchore、ドキュメントのみにはdocs、非意味論的な編集にはstyle、内部再構築にはrefactor、テストにはtest、パフォーマンスにはperfを使用します。 - 破壊的変更は
!またはBREAKING CHANGEフッターでマークし、それ以外の正確なタイプは変更しません。 - スカッシュされていないすべての開発コミットは、一貫性があり、Conventional Commits に従っている必要があります。
fix(storage): 照合インデックスを保持
サーバーで展開された照合を、インデックス定義を比較する前に正規化します。
Issue: PROJECT-123
プルリクエスト
- タイトルは、意図するスカッシュコミットの件名と正確に一致させます。
- 初期本文は、意図するスカッシュコミットの本文とフッターと正確に一致させます。PR専用の前置き、チェックリスト、実装日誌は含めません。
- PRの本文は手動で折り返さないでください。GitHubが表示折り返しを処理します。
- 永続的な履歴を簡潔に保ちます: 動機、重要な動作、副作用を記録します。
- 実験、代替案、広範な検証、実装の経過は、追跡コメントに記述します。
- 変更された行を、少なくともプロダクションコード、テスト、その他のファイルに分割して追跡コメントを投稿します。これによりレビュアーは変更内容を読む前にその重みを把握できます。カウント方法や提示方法はご自身で決めて結構ですが、差分が大きく変わった場合は更新します。
- タイトルと初期本文は、実装の進化に合わせて更新します。
- オープン、更新、マージの前に、
タイトル + 空行 + 本文を1つのコミットメッセージとして読み、矛盾があれば修正します。