github-flow

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. レビュー依頼

作業が完了したら以下を行います。

1. PR のステータスを Ready for Review に変更する
2. レビュアーをアサインする
3. 必要に応じてコメントで補足説明を追加する

---

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 を使用

---

クイックリファレンス

# 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番号>-<説明>