github-flow

# GitHub Flow 開発ガイド このリポジトリでは **GitHub Flow** を採用しています。すべてのコード変更は、以下のフローに従って行ってください。 --- ## フロー概要 ``` main（保護ブランチ） │ ├─ feature/<issue番号>-<短い説明> ブランチを作成 │ ├─ 作業・コミット（Conventional Commits） │ ├─ dotnet build / dotnet test で品質確認 │ └─ Draft PR を作成 │ ├─ 作業完了後 → Ready for Review に変更 │ ├─ レビュー実施 │ └─ Squash Merge → main へ統合 │ └─ ブランチ削除 ``` --- ## 1. ブランチの作成 `main` ブランチから feature ブランチを切ります。**直接 `main` にコミットしてはいけません。** ### ブランチ命名規則 ``` feature/<issue番号>-<短い説明> ``` | 例 | 説明 | |---|------| | `feature/42-add-search` | Issue #42 に対応する検索機能追加 | | `feature/15-fix-pagination` | Issue #15 のページネーション不具合修正 | ### コマンド例 ```bash git switch main git pull origin main git switch -c feature/42-add-search ``` --- ## 2. コミット規約（Conventional Commits） すべてのコミットメッセージは [Conventional Commits](https://www.conventionalcommits.org/ja/) に従います。 ### フォーマット ``` <type>(<scope>): <description> [本文（任意）] [フッター（任意）] ``` ### type 一覧 | type | 用途 | |------|------| | `feat` | 新機能の追加 | | `fix` | バグ修正 | | `docs` | ドキュメントのみの変更 | | `style` | コードの意味に影響しない変更（空白、フォーマット等） | | `refactor` | バグ修正でも機能追加でもないコード変更 | | `test` | テストの追加・修正 | | `chore` | ビルドプロセスや補助ツールの変更 | ### scope の例 プロジェクトのモジュール構成に応じて scope を定義します。以下は典型的な例です。 | scope | 対象 | |-------|------| | `<module>` | 対象モジュール全般 | | `<module>-domain` | <ModuleName>.Domain プロジェクト | | `<module>-app` | <ModuleName>.Application プロジェクト | | `<module>-infra` | <ModuleName>.Infrastructure プロジェクト | | `web` | Web プロジェクト（Blazor UI） | | `apphost` | AppHost プロジェクト（Aspire） | | `skill` | GitHub Copilot スキル | ### コミットメッセージの例 ``` feat(orders): 注文一覧の検索機能を追加 GetOrdersUseCase に検索パラメータを追加し、 リポジトリの検索メソッドを実装した。 Refs #42 ``` ``` fix(web): 一覧画面のページネーションが正しく動作しない問題を修正 Refs #15 ``` --- ## 3. ビルド・テスト・テスト作成の確認 PR を作成する**前**に、必ずローカルでビルドとテストを実行して成功を確認してください。 ```bash cd src dotnet build <YourSolution>.slnx dotnet test <YourSolution>.slnx ``` > **注意:** ビルドエラーやテスト失敗がある状態で PR を作成しないでください。 ### テスト作成の義務 新規・変更したビジネスロジックには **単体テストを必ず作成** してください。 - テストの書き方 → `csharp-mstest` スキルを参照 - テストプロジェクトの配置規約 → `clean-architecture-guide` スキルを参照 - 単体テストは `<ModuleName>.Application.Tests` プロジェクトに配置する - DTO・インターフェースのみの変更など、テスト対象のロジックがない場合はテスト不要 --- ## 4. Draft PR の作成 feature ブランチをリモートにプッシュし、**Draft Pull Request** を作成します。 ```bash git push -u origin feature/42-add-search ``` ### PR タイトル Conventional Commits と同じ形式にします。 ``` feat(orders): 注文一覧の検索機能を追加 ``` ### PR 本文テンプレート ```markdown ## 概要 <!-- 変更の目的と背景を簡潔に記述 --> ## 変更内容 <!-- 主な変更点を箇条書きで記述 --> - - ## 関連 Issue <!-- 対応する Issue を記載 --> Closes #<issue番号> ## 確認事項 - [ ] `dotnet build <YourSolution>.slnx` が成功する - [ ] `dotnet test <YourSolution>.slnx` が成功する - [ ] 新規・変更したビジネスロジックに単体テストがある（`csharp-mstest` スキル参照） - [ ] テストプロジェクトの配置が規約に従っている（`clean-architecture-guide` スキル参照） ``` ### Draft PR として作成する理由 - 作業中であることをチームに共有できる - 早い段階でフィードバックを得られる - CI が走り、問題を早期検出できる --- ## 5. レビュー依頼 作業が完了したら以下を行います。 1. PR のステータスを **Ready for Review** に変更する 2. レビュアーをアサインする 3. 必要に応じてコメントで補足説明を追加する --- ## 6. レビューとマージ ### レビュアーの作業 - コードの品質・設計を確認する - 必要に応じてコメントや修正リクエストを行う - 問題がなければ Approve する ### マージ方法 **Squash and Merge** を使用します。 - feature ブランチの複数コミットが 1 つのコミットにまとまる - `main` ブランチの履歴がクリーンに保たれる - マージコミットのメッセージは PR タイトルを使用する ### マージ後 - feature ブランチは**削除**する（GitHub の自動削除設定を推奨） - ローカルの不要ブランチも整理する ```bash git switch main git pull origin main git branch -d feature/42-add-search ``` --- ## 禁止事項 | やってはいけないこと | 代わりにやること | |---|---| | `main` ブランチに直接コミット | feature ブランチを作成してから作業 | | ビルドが通らない状態で PR 作成 | `dotnet build` / `dotnet test` を先に実行 | | Force push を `main` に実行 | feature ブランチでのみ必要に応じて使用 | | レビューなしでマージ | 必ずレビュー承認を経てからマージ | | Merge commit や Rebase merge | Squash Merge を使用 | --- ## クイックリファレンス ```bash # 1. ブランチ作成 git switch main && git pull origin main git switch -c feature/<issue番号>-<説明> # 2. 作業・コミット git add . git commit -m "feat(<scope>): 変更内容の説明" # 3. ビルド確認 cd src && dotnet build <YourSolution>.slnx && dotnet test <YourSolution>.slnx # 4. プッシュ & Draft PR 作成 git push -u origin feature/<issue番号>-<説明> # GitHub で Draft PR を作成 # 5. 完了後 → Ready for Review → レビュー → Squash Merge # 6. マージ後のクリーンアップ git switch main && git pull origin main git branch -d feature/<issue番号>-<説明> ```