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