creating-pr

PR の作成

レビューやマージがしやすいプルリクエストにまとめます。

ワークフロー

1. ブランチを準備する

PR を作成する前に：

# Ensure branch is up to date with base
git fetch origin
git rebase origin/main  # or merge, depending on project convention

# Check what will be in the PR
git log origin/main..HEAD --oneline
git diff origin/main --stat

プロジェクトでクリーンな履歴が推奨されている場合は、修正用コミットをスカッシュします。細かい履歴が推奨されている場合は、論理的にまとまったコミットを分けておきます。

2. タイトルを書く

形式：<type>: <short description>

種類	用途
feat	新機能
fix	バグ修正
refactor	バグ修正にも機能追加にも該当しないコード変更
docs	ドキュメントのみの変更
test	テストの追加または修正
chore	ビルド、CI、依存関係、またはツール関連
perf	パフォーマンスの改善

例：

• feat: add dark mode toggle to settings page
• fix: prevent duplicate form submissions on checkout
• refactor: extract auth middleware into shared module

3. 説明を書く

次の構成を使用します：

## Summary

1-3 sentences explaining what this PR does and why.

Closes #123

## Changes

- Added `ThemeToggle` component with system/light/dark options
- Updated `Layout` to read theme from context
- Added theme persistence to localStorage

## Test Plan

- [ ] Toggle between light/dark/system themes
- [ ] Refresh page — theme persists
- [ ] Check no flash of unstyled content on load

4. セルフレビュー

レビューを依頼する前に：

• 差分のすべての行を自分で読む
• デバッグ用コード（console.log、TODO、コメントアウトされたコード）を削除する
• テストが通ることを確認する：npm test
• 型を確認する：npx tsc --noEmit
• リントを確認する：npm run lint
• コミットすべきでないファイル（.env、ロックファイルの競合）がないか確認する

5. PR を作成する

git push -u origin HEAD
gh pr create --title "<title>" --body "$(cat <<'EOF'
## Summary
...

## Changes
...

## Test Plan
...
EOF
)"

6. レビューを依頼する

• 適切なレビュアー（コードオーナー、ドメインの専門家）を指定する
• PR が大きい場合（400 行超）は、ファイルをレビューするおすすめの順序を説明するコメントを追加する
• PR が別の PR に依存している場合は、説明に記載する
• PR に適切なラベル（機能、バグ、破壊的変更など）を付ける

ヒント

• 小さな PR はレビューが早くなります。変更行数は 300 行未満を目指しましょう
• PR が大きすぎる場合は、積み重ね型の PR に分割します
• UI の変更にはスクリーンショットや録画を添えると、レビューが大幅に早くなります
• 作業が完了する前に早めのフィードバックを得るには、ドラフト PR が便利です