プルリクエストの作成

このスキルでは、プロジェクト規約とベストプラクティスに従った、よく構造化された GitHub プルリクエストを作成するプロセスを説明します。

前提条件の確認

進める前に、以下を確認してください：

1. gh CLI がインストールされているか確認

gh --version

インストールされていない場合は、ユーザーに以下を案内します：

GitHub CLI (gh) が必要ですがインストールされていません。以下からインストールしてください：

• macOS: brew install gh
• その他: https://cli.github.com/

2. GitHub で認証されているか確認

gh auth status

認証されていない場合は、ユーザーに gh auth login の実行をガイドしてください。

3. クリーンなワーキングディレクトリを確認

git status

コミットされていない変更がある場合は、ユーザーに以下のいずれかを選択するよう求めます：

• このプルリクエストの一部としてコミットする
• 一時的にスタッシュする
• 破棄する（慎重に）

コンテキストの収集

1. 現在のブランチを特定

git branch --show-current

main または master 上にないことを確認してください。上にある場合は、ユーザーにフィーチャーブランチの作成または切り替えを求めます。

2. ベースブランチを見つける

git remote show origin | grep "HEAD branch"

これは通常 main または master です。

3. このプルリクエストに関連する最近のコミットを分析

git log origin/main..HEAD --oneline --no-decorate

これらのコミットをレビューして、以下を理解します：

• 導入される変更内容
• プルリクエストの範囲（単一フィーチャー/修正または複数の変更）
• コミットをスクワッシュまたは再構成する必要があるかどうか

4. diff をレビュー

git diff origin/main..HEAD --stat

どのファイルが変更されたかを表示し、変更のタイプを特定するのに役立ちます。

情報の収集

プルリクエストを作成する前に、以下の情報が必要です。以下から推測できるか確認してください：

• コミットメッセージ
• ブランチ名（例：fix/issue-123、feature/new-login）
• 変更されたファイルとその内容

重要な情報が不足している場合は、ask_followup_question を使用してユーザーに質問します：

必須情報

1. 関連する Issue 番号：コミットメッセージまたはブランチ名に #123、fixes #123、closes #123 などのパターンを探す
2. 説明：この変更は何の問題を解決しますか？なぜこれらの変更が必要ですか？
3. 変更のタイプ：バグ修正、新機能、破壊的変更、リファクタリング、コスメティック、ドキュメント、またはワークフロー
4. テスト手順：これはどのようにテストされましたか？何が壊れる可能性がありますか？

例：確認質問

Issue 番号が見つからない場合：

コミットメッセージまたはブランチ名に関連する Issue 番号が見つかりませんでした。このプルリクエストが対応する GitHub Issue はどれですか？（Issue 番号を入力してください。例：「123」または小さな修正の場合は「N/A」）

Git のベストプラクティス

プルリクエストを作成する前に、以下のベストプラクティスを検討してください：

コミットの衛生管理

1. アトミックコミット：各コミットは単一のロジカルな変更を表す
2. 明確なコミットメッセージ：可能な限り Conventional Commit 形式に従う
3. マージコミットなし：履歴をクリーンに保つため、マージよりもリベースを優先する

ブランチ管理

1. 最新の main にリベース（必要に応じて）：

   git fetch origin
   git rebase origin/main
   

2. 適切な場合はスクワッシュ：多くの小さな「WIP」コミットがある場合、インタラクティブリベースを検討します：

   git rebase -i origin/main
   

   コミットが雑多に見え、ユーザーがリベースに慣れている場合にのみ推奨してください。

変更をプッシュ

すべてのコミットがプッシュされていることを確認します：

git push origin HEAD

ブランチがリベースされた場合は、次のが必要になる場合があります：

git push origin HEAD --force-with-lease

プルリクエストの作成

重要：.github/pull_request_template.md のプルリクエストテンプレートを読み、使用してください。プルリクエスト本文のフォーマットは、テンプレート構造に厳密に一致する必要があります。テンプレートフォーマットから逸脱しないでください。

テンプレートを記入する際：

• #XXXX を実際の Issue 番号に置き換えるか、Issue が存在しない場合（小さな修正の場合）は #XXXX のまま保つ
• コミットおよびコンテキストから収集した情報ですべてのセクションを記入する
• 適切な「Type of Change」チェックボックスをマークする
• 適用可能な「Pre-flight Checklist」項目を完成させる

gh CLI でプルリクエストを作成

シェルエスケープの問題、改行の問題、その他のコマンドライン上の不安定性を避けるため、プルリクエスト本文に一時ファイルを使用します：

1. プルリクエスト本文を一時ファイルに書き込みます：

   /tmp/pr-body.md
   

2. ファイルを使用してプルリクエストを作成します：

   gh pr create --title "PR_TITLE" --body-file /tmp/pr-body.md --base main
   

3. 一時ファイルをクリーンアップします：

   rm /tmp/pr-body.md
   

ドラフトプルリクエストの場合：

gh pr create --title "PR_TITLE" --body-file /tmp/pr-body.md --base main --draft

なぜファイルを使うのか？ 改行、特殊文字、チェックボックスを含む複雑な Markdown を --body で直接渡すのはエラーが起きやすいです。--body-file フラグはすべてのコンテンツを確実に処理します。

作成後

プルリクエストを作成した後：

1. プルリクエスト URL を表示：ユーザーが確認できるようにします
2. CI チェックを思い出させる：テストと lint は自動的に実行されます
3. 次のステップを提案：
   • 必要に応じてレビュアーを追加：gh pr edit --add-reviewer USERNAME
   • 必要に応じてラベルを追加：gh pr edit --add-label "bug"

エラーハンドリング

一般的な問題

1. main より先のコミットがない：ブランチに送信する変更がない

   • ユーザーが別のブランチで作業するつもりだったのかを確認します

2. ブランチがプッシュされていない：リモートにブランチがない

   • 最初にブランチをプッシュ：git push -u origin HEAD

3. プルリクエストが既に存在：このブランチに対するプルリクエストが既に存在する

   • 既存のプルリクエストを表示：gh pr view
   • 代わりに更新するかを尋ねます

4. マージコンフリクト：ブランチがベースとコンフリクト

   • ユーザーをコンフリクト解決またはリベースのガイダンスに導きます

サマリーチェックリスト

最終化する前に、以下を確認します：

• gh CLI がインストールされ認証されている
• ワーキングディレクトリがクリーン
• すべてのコミットがプッシュされている
• ブランチがベースブランチの最新版と同期している
• 関連する Issue 番号が特定されている、またはプレースホルダーが使用されている
• プルリクエストの説明がテンプレートに完全に従っている
• 適切な変更タイプが選択されている
• Pre-flight チェックリスト項目が対応されている