Git Pr

/git-pr

プルリクエストを作成（未プッシュなら自動プッシュ、既存PRがあれば更新）

使用方法

/git-pr [--base BASE_BRANCH] [--draft]

引数:

• --base BASE_BRANCH: ベースブランチを指定（省略時: デフォルトブランチ）
• --draft: ドラフトPRとして作成

例:

/git-pr                              # デフォルトブランチに通常PR
/git-pr --draft                      # ドラフトPRとして作成
/git-pr --base feature/xxx-xxx       # featureブランチをベースに通常PR
/git-pr --base feature/xxx-xxx --draft  # featureブランチをベースにドラフトPR

実行内容

1. 状態確認・プッシュ

1. git status で現在のブランチと未プッシュコミットを確認
2. 未プッシュのコミットがあれば git push -u origin [current-branch] でプッシュ
3. gh pr list --head [current-branch] で既存PRの有無を確認

2. 差分確認

4. git diff [base]...HEAD でベースブランチからの差分を確認
   • 差分が大きい場合は --name-only で変更ファイル一覧を取得後、個別に確認
   • 変更内容を把握してからPR説明文を作成

3A. 既存PRがない場合（新規作成）

5. gh pr list --limit 5 で最近のPRから言語慣例（日本語/英語）を確認
6. プルリクエストテンプレート（.github/pull_request_template.md）があれば参照
7. プロジェクトの言語慣例に従ってタイトルと説明を決定（下記ガイドライン参照）
8. gh pr create でPRを作成：
   • --base オプション: 指定されたベースブランチ（省略時はデフォルト）
   • --draft オプション: 指定された場合のみドラフトPRとして作成

3B. 既存PRがある場合（更新判定）

5. gh pr view で現在のPRタイトル・説明を取得
6. 差分内容と現在のPR説明を比較し、乖離がないか確認：
   • 新しいコミットが追加されている
   • PR説明に記載されていない変更がある
   • PR説明が古い実装内容を参照している
7. 乖離がある場合、更新内容を提案しユーザーに確認
8. 承認されれば gh pr edit でタイトル・説明を更新

PR説明のガイドライン

構成

Why（なぜ）を最初に書く。 PR説明で最も重要な要素。コードの差分は「何を変えたか」を示すが、「なぜ変えたか」はPR説明でしか伝わらない。

1. Why（なぜ）: この変更が必要になった背景・動機・課題
   • Issue起点: Issueの課題・要望を要約（リンクだけでなく本文に書く）
   • バグ修正: 何が問題で、どういう状況で発生していたか
   • リファクタリング: なぜ今この改善が必要か
2. What（何を）: 変更内容の要約。コードを読まずに理解できる程度
3. 関連リンク: Issue番号（Closes #99）、設計文書など（該当する場合）

レビュアーの疑問を先回りする

差分を読んだレビュアーが「なぜこうした？」と質問しそうな箇所を予測し、PR説明に含める。

• 設計判断の根拠: 複数のアプローチがある中でこの方法を選んだ理由
• 不採用の代替案: 「Xも検討したがYの理由で不採用」（最もラウンドトリップを減らせる情報）
• 意図的にやらなかったこと: 影響範囲が広い変更で、あえて変更しなかった箇所とその理由
• 非自明な実装: フレームワークの制約やパフォーマンス上の理由による回避策

コードを読めば自明なことや、全ての判断を網羅する必要はない。レビュアーが実際に疑問を持ちそうな箇所に絞る。

含めないもの

• 実装の詳細な順序（レビュアーに不要）
• コードの詳細説明（コード内コメントにすべき）

Converted and distributed by TomeVault — claim your Tome and manage your conversions.