unopim-git

UnoPim の Git ワークフロー

UnoPim リポジトリでのブランチ、コミット、プルリクエストについて説明します。正式な情報源は、UnoPim のチェックアウト（$UNOPIM）内にある .github/CONTRIBUTING.md と .github/PULL_REQUEST_TEMPLATE.md です。このスキルとそれらのファイルに食い違いがある場合は、リポジトリ内のファイルを優先してください。

ブランチ

• メンテナーからバージョンブランチ（例：2.1）へのバックポートを求められない限り、master を対象にします。
• 1つのブランチで扱う修正は1つにし、課題 ID を使って issue-1234 のように命名します。
• 小文字とハイフンを使います。課題がない場合は、目的を示す接頭辞を付けます。 feature/short-description、refactor/short-description、test/short-description。

コミットメッセージ — Conventional Commits（必須）

.github/CONTRIBUTING.md では Conventional Commits 形式が必須とされており、件名の末尾に括弧付きで課題を記載します。

type(scope): imperative description (#1234)

• type：feat、fix、refactor、perf、test、ci、chore、docs。
• scope：変更したパッケージまたは領域 — admin、product、attribute、datagrid、core。
• 件名：命令形、小文字、末尾にピリオドを付けず、72文字以内。
• 任意の本文は、空行の後に「何を」ではなく「なぜ」を説明します。

良い例（実際の履歴から引用）：

fix(admin): prevent duplicate SKU on product creation (#1234)
feat(product): configurable association types with per-link fields (#570)
fix(attribute): copy a cloned family's attribute mappings in the database

悪い例 — 以下の形式でコミットを作成してはいけません。

Fixed #1234 - Prevent duplicate SKU     <- legacy format; not the repo convention
Update ProductController.php            <- no type(scope), describes the file not the change
fix: stuff                              <- no scope, vague

プルリクエスト

PR のタイトルには、コミットと同じ type(scope): description 形式を使います。 終了キーワード（Fixes #123）は本文の Issue Reference セクションに記載し、タイトルには絶対に含めないでください。

PR の本文には、.github/PULL_REQUEST_TEMPLATE.md の6つのセクションすべてを、指定された順序で含める必要があります：Issue Reference, Description, How To Test This?, Screenshots, Checklist, Documentation。セクションを省略せず、「How To Test This?」の名前も変更しないでください。

gh pr create --title "fix(admin): prevent duplicate SKU on product creation (#1234)" --body "$(cat <<'EOF'
## Issue Reference
Fixes #1234

## Description
Adds a unique-SKU guard to the product store flow so a double submit no longer
creates two products with the same SKU.

## How To Test This?
1. Open Catalog > Products and create a product with SKU `test-sku`.
2. Submit the create form twice in quick succession.
3. Only one product exists; the second submit returns a validation error.

## Screenshots
N/A — no UI change.

## Checklist
- [x] `vendor/bin/pest` passes locally
- [x] `vendor/bin/pint --test` reports no style issues
- [x] Tailwind classes are reordered
- [x] New user-facing strings use translation keys (all 33 locales)
- [x] Target branch is `master` (unless a maintainer requested a backport)

## Documentation
- [ ] My pull request requires an update on the documentation repository.
EOF
)"

• UI を変更する場合は、Screenshots のプレースホルダーを変更前と変更後の画像、または短い録画に置き換えます。それ以外の場合は、テンプレート上、そのセクションの内容を削除できますが、見出しは N/A とともに残してください。
• ドキュメントに影響する場合は、Documentation のチェックボックスにチェックを付け、変更が必要な内容を説明します。
• コマンドを実際に実行した後にのみ、Checklist のチェックボックスにチェックを付けてください。

CI ゲート — プッシュと PR ごとに6つのゲート

GitHub Actions は6つのゲートを実行します。プッシュする前に、すべてを必須のチェックとして扱ってください。

1. vendor/bin/pint --test — コードスタイル（linting_tests.yml）
2. MySQL と PostgreSQL での Pest スイート — composer test（pest_tests.yml、pest_tests_pgsql.yml）
3. Playwright E2E — cd tests/e2e-pw && npx playwright test（playwright_test.yml）
4. Larastan — composer phpstan（static_analysis.yml）。通過のために ignoreErrors を追加してはいけません。
5. Rector — composer rector-dry（static_analysis.yml。CI ではドライランのジョブは参考扱いですが、指摘事項は必ず修正し、withSkip を拡張してはいけません）。
6. php artisan unopim:translations:check — 33のロケールすべてを完成させます（translation_tests.yml）。

必須のサブスキル： ブランチをプッシュする前、または PR を開く前に、unopim-verify を使用してください。これは、ワークスペースに適したコマンドを使い、同じゲートをローカルで順番に実行します。ゲートに失敗した状態でプッシュしてはいけません。また、verify に合格していない PR を準備完了としないでください。

コントリビューションの手順

• セキュリティの脆弱性について、公開 GitHub issue を作成してはいけません。SECURITY.md の手順に従ってください。
• バグ修正：まず既存の issue を検索し、フォークして、issue ごとにブランチを作成し、master 宛てに PR を送ります。
• 機能追加：実装前に機能リクエストの issue を作成してください。