Appearance
7. feature の PR を作成する
概要
feature ブランチで実装したコードとテストをコミットし、GitHub へ push します。その後、feature ブランチの変更を develop ブランチへ取り込むための Pull Request を作成します。
Pull Request では、変更したコードだけでなく、変更の目的、関連する Issue、テストとビルドの結果をレビュー担当者へ共有します。作成すると CI が実行され、マージする前に変更内容と品質を確認できる状態になります。この段階では main へリリースせず、まず develop へ変更を統合します。
手順
1. 変更をコミットする
実装とテストの変更だけをコミットし、今回の Issue に対応する変更として記録できたことを確認します。
Agent モードで以下の指示を与えます。
1 は実際の Issue 番号へ置き換えます。
text
既存の AGENTS.md と git-workflow Skill のガードレールに従ってください。
現在のブランチと Issue #1 が対応していることを確認し、Issue と現在の差分に基づく適切なメッセージで、今回の実装に関係する変更だけを1件のコミットにしてください。
コミットの対象ファイル、メッセージ、影響を要約し、askQuestions で明示的な承認を得てから実行してください。
対象不明、状態不整合、秘密情報の疑いがあれば変更せず質問してください。コミット前後の状態を確認し、push は行わないでください。次を確認します。
- 現在のブランチと Issue が対応し、今回の実装に関係する変更だけが対象である
- コミットの対象ファイル、メッセージ、影響を確認して明示的に承認するまで実行されていない
- コミット前後の状態が報告されている
- push は実行されていない
powershell
# 現在のブランチと作業ツリーの状態を表示します
git status
# 実装ファイルとテストファイルをステージします
git add src/availability.js src/availability.test.js
# ステージした変更をコミットします
git commit -m "feat: highlight low availability"bash
# 現在のブランチと作業ツリーの状態を表示します
git status
# 実装ファイルとテストファイルをステージします
git add src/availability.js src/availability.test.js
# ステージした変更をコミットします
git commit -m "feat: highlight low availability"2. リモートへ push する
コミットが完了したら、現在の feature ブランチをリモートへ push します。
Agent モードで以下の指示を与えます。
text
既存の AGENTS.md と git-workflow Skill のガードレールに従ってください。
現在のブランチ、upstream、作業ツリー、直近コミット、origin を確認し、push 対象が今回の feature ブランチであることを示してください。
origin へ feature ブランチを初回 push する外部変更について、リポジトリ、ブランチ、コミット、影響を要約し、askQuestions で明示的な承認を得てから git push -u origin HEAD を実行してください。
対象不明、未コミット変更、ブランチや remote の不整合があれば push せず質問し、実行後に upstream と push 結果を確認してください。次を確認します。
- push 対象が今回の feature ブランチと直近コミットである
- リポジトリ、ブランチ、コミット、影響を確認して明示的に承認するまで push されていない
- 実行後の upstream と push 結果が報告されている
- ブランチや remote に不整合がある場合は push されていない
powershell
# 現在の feature ブランチを origin へ初回 push し、追跡先に設定します
git push -u origin HEADbash
# 現在の feature ブランチを origin へ初回 push し、追跡先に設定します
git push -u origin HEAD3. Pull Request を作成する
リモートへ push した feature ブランチから、develop ブランチへの Pull Request を作成します。
Agent モードで以下の指示を与えます。
GitHub CLI や GitHub MCP サーバー経由で Pull Request を作成できる環境で実行します。
text
/create-pr
既存の AGENTS.md と git-workflow Skill のガードレールに従い、作成前に対象リポジトリ、ベースが develop、ヘッドが現在の feature ブランチ、タイトル、変更概要、実行済みの確認結果、Related to #<Issue番号> を要約してください。
Pull Request 作成は外部変更のため、askQuestions で明示的な承認を得るまで作成しないでください。対象不明、ベース／ヘッドの不整合、未 push のコミット、テスト結果不明があれば変更せず質問してください。
承認後に1件だけ作成し、URL とベース／ヘッドを確認して報告してください。次を確認します。
- 対象リポジトリ、ベースが
develop、ヘッドが現在の feature ブランチである - タイトル、変更概要、実行済みの確認結果、
Related to #<Issue番号>が実際の内容と一致している - 外部変更の対象と影響を確認して明示的に承認するまで Pull Request が作成されていない
- 承認後に1件だけ作成され、URL とベース／ヘッドが報告されている
powershell
# 現在の GitHub リポジトリの完全な名前を取得します
$repo = (gh repo view --json nameWithOwner | ConvertFrom-Json).nameWithOwner
# 未完了 Issue の番号とタイトルを取得します
$issues = gh issue list --repo $repo --state open --limit 100 --json number,title |
ConvertFrom-Json
# 演習で作成した Issue を選択します
$issue = $issues |
Where-Object { $_.title -eq "残席が少ないイベントを分かりやすくする" } |
Select-Object -First 1
# Issue 番号と現在の feature ブランチ名を変数へ保存します
$issueNumber = $issue.number
$featureBranch = git branch --show-current
# develop 向けの Pull Request を作成します
$featurePrUrl = gh pr create --repo $repo `
--base develop `
--head $featureBranch `
--title "feat: 残席が少ないイベントを強調する" `
--body @"
## 変更概要
- 残席が1〜3席の場合に「残席わずか」と表示
- 境界値3席と4席のテストを追加
## 動作確認
- npm test
- npm run build
Related to #$issueNumber
"@
# 作成した Pull Request の URL を表示します
$featurePrUrlbash
# 現在の GitHub リポジトリの完全な名前を取得します
repo=$(gh repo view --json nameWithOwner --jq .nameWithOwner)
# 演習で作成した Issue の番号を取得します
issue_number=$(gh issue list --repo "$repo" --state open --limit 100 --json number,title \
--jq '.[] | select(.title == "残席が少ないイベントを分かりやすくする") | .number' |
head -n 1)
# 現在の feature ブランチ名を取得します
feature_branch=$(git branch --show-current)
# develop 向けの Pull Request を作成し、その URL を保存します
feature_pr_url=$(gh pr create --repo "$repo" \
--base develop \
--head "$feature_branch" \
--title "feat: 残席が少ないイベントを強調する" \
--body "$(cat <<EOF
## 変更概要
- 残席が1〜3席の場合に「残席わずか」と表示
- 境界値3席と4席のテストを追加
## 動作確認
- npm test
- npm run build
Related to #$issue_number
EOF
)")
# 作成した Pull Request の URL を表示します
printf '%s\n' "$feature_pr_url"- GitHub で演習用リポジトリを開き、Pull requests を選択します。
- New pull request を選択します。
- ベースに
develop、比較対象にfeature/<Issue番号>-low-availabilityを選択します。 - Create pull request を選択します。
- タイトルに「feat: 残席が少ないイベントを強調する」と入力します。
<Issue番号>を実際の番号へ置き換え、次の本文を入力します。- Create pull request を選択します。
markdown
## 変更概要
- 残席が1〜3席の場合に「残席わずか」と表示
- 境界値3席と4席のテストを追加
## 動作確認
- [x] `npm test`
- [x] `npm run build`
Related to #<Issue番号>確認事項
- ベースが
develop、ヘッドがfeature/<Issue番号>-low-availabilityである - Pull Request の本文に変更概要と実行済みの確認結果が記載されている
- Pull Request の本文に
Related to #<Issue番号>が含まれている - 変更対象が
src/availability.jsとsrc/availability.test.jsの2ファイルだけである
まとめ
feature ブランチの変更をコミット、push し、develop ブランチへの Pull Request を作成しました。Pull Request には変更概要、テストとビルドの結果、関連する Issue を記載したため、レビュー担当者は「なぜ変更したか」「何を変更したか」「どのように確認したか」を1か所で把握できます。
この段階では Related to #<Issue番号> を使用し、Issue を閉じずに参照しました。feature ブランチから develop へのマージは中間統合であり、GitHub の自動クローズは既定ブランチ向け Pull Request でだけ機能します。後で作成する develop から main への Pull Request に Closes #<Issue番号> を記載し、リリース時に Issue を閉じます。
補足: 実務で役立つ Pull Request の作り方
- Pull Request を小さく保つと、レビュー担当者が意図と差分を理解しやすくなり、不具合が見つかった場合の修正や切り戻しも容易になります。
- タイトルには変更の目的、本文には背景、変更概要、確認方法、関連 Issue を記載します。コードを読まなくても変更の全体像が分かる内容を目指します。
- ベースとヘッドを取り違えると、意図しない差分やコミットが含まれます。作成前後に必ず確認します。
- テスト結果は実際に実行したものだけを記載します。未確認の項目を成功済みとして記載しないでください。
- 大きな変更や設計に迷う変更では、実装途中でも Draft Pull Request を作成すると、早い段階でフィードバックを受けられます。
- Pull Request テンプレートを用意すると、変更概要、テスト、影響範囲など、チームで必要な情報の記載漏れを減らせます。
- 自動生成された本文もそのまま使用せず、実際の差分と一致し、レビュー担当者に必要な情報が含まれているか確認します。
次は、Pull Request で実行された CI の結果と変更差分を確認し、人によるレビューを経て develop へマージします。