create-pull-request

プルリクエストを作成する

このスキルでは、プロジェクトの規約とベストプラクティスに沿った、適切に構成された 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

コミットされていない変更がある場合は、ユーザーに次のどれを行うか尋ねます。

• この PR の一部としてコミットする
• 一時的に退避する
• 破棄する（慎重に行う）

コンテキストの収集

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

git branch --show-current

main または master ブランチにいないことを確認します。いずれかのブランチにいる場合は、フィーチャーブランチを作成するか、そのブランチに切り替えるようユーザーに依頼します。

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

git remote show origin | grep "HEAD branch"

通常は main または master です。

3. この PR に関連する最近のコミットを分析する

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

これらのコミットを確認して、以下を把握します。

• どのような変更が導入されるか
• PR の範囲（単一の機能・修正か、複数の変更か）
• コミットをスカッシュするか、再編成する必要があるか

4. 差分を確認する

git diff origin/main..HEAD --stat

変更されたファイルが表示され、変更の種類を特定するのに役立ちます。

情報の収集

PR を作成する前に、以下の情報が必要です。次の内容から推測できるか確認します。

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

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

必要な情報

1. 関連する Issue 番号：コミットメッセージに #123、fixes #123、closes #123 のようなパターンがないか確認します
2. 説明：どのような問題を解決するのか、なぜこれらの変更を行ったのか
3. 変更の種類：バグ修正、新機能、破壊的変更、リファクタリング、外観上の変更、ドキュメント、ワークフロー
4. テスト手順：どのようにテストしたか、何が壊れる可能性があるか

質問の例

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

コミットメッセージやブランチ名に、関連する Issue 番号が見つかりませんでした。この PR が対応する GitHub Issue を教えてください（例：「123」、小規模な修正の場合は「N/A」）。

Git のベストプラクティス

PR を作成する前に、以下のベストプラクティスを検討します。

コミットの整理

1. アトミックなコミット：各コミットは、単一の論理的な変更を表すようにします
2. 明確なコミットメッセージ：可能であれば、Conventional Commits の形式に従います
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 の PR テンプレートを読み、使用してください。PR 本文の形式は、テンプレートの構成に厳密に従う必要があります。テンプレートの形式から逸脱しないでください。

テンプレートに記入する際は、以下のとおりにします。

• #XXXX を実際の Issue 番号に置き換えます。Issue がない場合（小規模な修正）は #XXXX のままにします
• コミットとコンテキストから収集した関連情報を、すべてのセクションに記入します
• 適切な「変更の種類」のチェックボックスにチェックを入れます
• 該当する「リリース前チェックリスト」の項目を完了します

gh CLI で PR を作成する

シェルのエスケープ処理や改行の問題、その他のコマンドラインでの不安定さを避けるため、PR の本文には一時ファイルを使用します。

1. PR の本文を一時ファイルに書き込みます。

   /tmp/pr-body.md
   

2. ファイルを使用して PR を作成します。

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

3. 一時ファイルを削除します。

   rm /tmp/pr-body.md
   

ドラフト PR の場合：

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

ファイルを使用する理由：改行、特殊文字、チェックボックスを含む複雑な Markdown を --body で直接渡すと、エラーが発生しやすくなります。--body-file フラグを使えば、すべての内容を確実に処理できます。

作成後

PR を作成した後：

1. ユーザーが確認できるよう、PR の 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. PR がすでに存在する：このブランチの PR がすでに存在します

   • 既存の PR を表示します：gh pr view
   • 代わりに既存の PR を更新するか、ユーザーに確認します

4. マージコンフリクト：ブランチとベースブランチが競合しています

   • コンフリクトの解決またはリベースの手順をユーザーに案内します

最終確認チェックリスト

完了前に、以下を確認します。

• gh CLI がインストールされ、認証されている
• 作業ディレクトリがクリーンである
• すべてのコミットがプッシュされている
• ブランチがベースブランチの最新状態になっている
• 関連する issue 番号が特定されているか、プレースホルダーが使用されている
• PR の説明がテンプレートに正確に従っている
• 適切な変更の種類が選択されている
• 事前確認チェックリストの項目に対応している