Appearance
9. main へ統合する
概要
前の記事では、feature ブランチの変更を開発用の develop ブランチへ統合しました。この章では、develop に集めた変更を公開用の main ブランチへ取り込むため、リリース用の Pull Request を作成し、レビューと CI を確認してマージします。
feature ブランチから develop への Pull Request は、個別の変更を開発中のコードへ統合するためのものでした。今回の develop から main への Pull Request は、リリースする変更全体を最終確認するためのものです。差分、コミット、CI、関連 Issue を確認し、本文に Closes #<Issue番号> を記載して、main へのマージ時に Issue が自動で閉じるようにします。
手順
1. リリース対象を確認する
ローカルの develop ブランチを最新にし、main へ取り込むコミットを確認します。ここでは、ローカルとリモートが同期していること、意図した変更だけが含まれていること、関連する Pull Request と Issue を特定できること、テスト・ビルド・CI が成功していることを確認します。問題がある場合は、リリース用 Pull Request を作成する前に解決します。
Agent モードで以下の指示を与えます。
text
/prepare-release次を確認します。
- 現在のブランチが
developで、作業ツリーに未コミットの変更がなく、ローカルとリモートが同期している mainに未統合のコミットと変更ファイルがリリース対象として妥当である- 関連する Pull Request と Issue を特定でき、
Closesを記載する Issue が正しい npm test、npm run build、developの CI が成功している- すべて通過した場合は
Ready、解決が必要な場合はBlockedと報告され、Blockedの場合は Pull Request の作成へ進まない
powershell
# develop ブランチへ切り替えます
git switch develop
# リモートの develop ブランチを fast-forward で取り込みます
git pull --ff-only
# 作業ツリーに未コミットの変更がないことを確認します
git status
# main にまだ含まれていない develop のコミットを表示します
git log --oneline main..developbash
# develop ブランチへ切り替えます
git switch develop
# リモートの develop ブランチを fast-forward で取り込みます
git pull --ff-only
# 作業ツリーに未コミットの変更がないことを確認します
git status
# main にまだ含まれていない develop のコミットを表示します
git log --oneline main..develop2. Pull Request を作成する
develop をヘッド、main をベースとする Pull Request を作成します。GitHub CLI を使用する場合は、必要な値を GitHub から取得し直します。
Agent モードで以下の指示を与えます。
text
/create-pr
既存の AGENTS.md と git-workflow Skill のガードレールに従い、作成前に対象リポジトリ、ベースが main、ヘッドが develop、タイトル、リリース差分、実行済みの確認結果、Closes #<Issue番号> を要約してください。
Pull Request 作成は外部変更のため、askQuestions で明示的な承認を得るまで作成しないでください。対象不明、ベース／ヘッドの不整合、prepare-release が Blocked、テスト結果不明なら変更せず質問してください。
承認後に1件だけ作成し、URL、ベース／ヘッド、Closes の対象 Issue を確認して報告してください。次を確認します。
- 対象リポジトリ、ベースが
main、ヘッドがdevelopである - タイトル、リリース差分、確認結果、
Closes #<Issue番号>が実際の内容と一致している prepare-releaseがReadyで、明示的に承認するまで Pull Request が作成されていない- 承認後に1件だけ作成され、URL、ベース／ヘッド、Closes の対象 Issue が報告されている
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 の番号を取得します
$issueNumber = ($issues |
Where-Object { $_.title -eq "残席が少ないイベントを分かりやすくする" } |
Select-Object -First 1).number
# main 向けの release Pull Request を作成し、その URL を保存します
$releasePrUrl = gh pr create `
--repo $repo `
--base main `
--head develop `
--title "release: 残席表示を改善する" `
--body "Closes #$issueNumber`n`n## 変更`n- 残席3席以下を強調`n- 境界値テストを追加`n`n## 確認`n- npm test`n- npm run build"
# 作成した release Pull Request の URL を表示します
$releasePrUrlbash
# 現在の 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)
# main 向けの release Pull Request を作成し、その URL を保存します
release_pr_url=$(gh pr create \
--repo "$repo" \
--base main \
--head develop \
--title "release: 残席表示を改善する" \
--body "$(cat <<EOF
Closes #$issue_number
## 変更
- 残席3席以下を強調
- 境界値テストを追加
## 確認
- npm test
- npm run build
EOF
)")
# 作成した release Pull Request の URL を表示します
printf '%s\n' "$release_pr_url"- GitHub で演習用リポジトリを開き、Pull requests、New pull request の順に選択します。
- ベースに
main、比較対象にdevelopを選択します。 - Create pull request を選択します。
- タイトルに「release: 残席表示を改善する」と入力します。
<Issue番号>を実際の番号へ置き換え、次の本文を入力します。- Create pull request を選択します。
markdown
## 変更概要
- 残席が1〜3席の場合に「残席わずか」と表示
- 境界値3席と4席のテストを追加
## 動作確認
- [x] `npm test`
- [x] `npm run build`
Closes #<Issue番号>3. リリース内容をレビューする
レビュー担当者の責務
この作業はレビュー担当者として行います。実装担当者とは別の視点で、develop に統合されたリリース対象、関連 Issue、CI、差分を確認し、main へマージしてよいかを判断します。
リリース用 Pull Request の差分、CI、関連 Issue を確認し、main へ統合してよい状態か判断します。
Agent モードで以下の指示を与えます。
2 を、main 向け Pull Request の実際の番号へ置き換えます。
text
/review-pr 2
ベースが main、ヘッドが develop であることを含め、Pull Request の CI、差分、コミット、関連 Issue、Closes の対象を読み取り専用で確認してください。
不要なファイル、意図しない依存関係、失敗または未完了のチェックがあれば明示し、マージ、レビュー送信、ファイル変更は行わないでください。次を確認します。
- ベースが
main、ヘッドがdevelopである - CI、差分、コミット、関連 Issue、
Closesの対象に不整合がない - 不要なファイル、意図しない依存関係、失敗または未完了のチェックが報告されている
- マージ、レビュー送信、ファイル変更が行われていない
powershell
# 現在の GitHub リポジトリの完全な名前を取得します
$repo = (gh repo view --json nameWithOwner | ConvertFrom-Json).nameWithOwner
# main 向けに開いている release Pull Request の URL を取得します
$releasePrUrl = (gh pr list --repo $repo --base main --head develop --state open --json url |
ConvertFrom-Json |
Select-Object -First 1).url
# release Pull Request の変更差分を表示します
gh pr diff $releasePrUrl --repo $repo
# release Pull Request のチェック結果を表示します
gh pr checks $releasePrUrl --repo $repobash
# 現在の GitHub リポジトリの完全な名前を取得します
repo=$(gh repo view --json nameWithOwner --jq .nameWithOwner)
# main 向けに開いている release Pull Request の URL を取得します
release_pr_url=$(gh pr list --repo "$repo" --base main --head develop --state open --json url \
--jq '.[0].url')
# release Pull Request の変更差分を表示します
gh pr diff "$release_pr_url" --repo "$repo"
# release Pull Request のチェック結果を表示します
gh pr checks "$release_pr_url" --repo "$repo"Pull Request の Conversation、Commits、Files changed、Checks を確認します。右側の Development に対象 Issue が表示され、マージ時に閉じることも確認します。
4. main へマージする
マージ担当者の責務
この作業は、リポジトリでマージ権限を持つ担当者が行います。チームのルールに従ってレビュー結果と CI を再確認し、承認されたリリース対象だけを main へ統合します。本ハンズオンでは、演習用リポジトリの Owner がマージ担当者を兼ねます。
- GitHub で release Pull Request を開きます。
- Checks が成功し、必要なレビューが完了していることを確認します。
- ベースが
main、ヘッドがdevelopであることを確認します。 - 右側の Development に、マージ時に自動で閉じる対象 Issue が表示されていることを確認します。
- Pull Request の末尾でマージ方法に Create a merge commit を選択します。
- Merge pull request、Confirm merge の順に選択します。
- ローカルの
mainブランチを、マージ後の状態へ更新します。
マージ済みの main をローカルへ fast-forward で取り込み、公開対象の最新コミットを参照できる状態にします。
Agent モードで以下の指示を与えます。
text
既存の AGENTS.md と git-workflow Skill のガードレールに従ってください。
release Pull Request がベース main、ヘッド develop でマージ済みであること、作業ツリーが clean であること、現在のブランチと origin/main の状態を確認してください。
問題がなければローカルを main へ切り替え、fast-forward のみで origin/main を取り込んでください。未コミット変更、競合、履歴不整合があれば変更せず質問してください。
実行後に現在のブランチと最新コミットを報告し、push は行わないでください。次を確認します。
- release Pull Request がベース
main、ヘッドdevelopでマージ済みである - 作業ツリーが clean であり、ローカルの
mainが fast-forward で更新されている - 現在のブランチと最新コミットが報告されている
- push は行われていない
powershell
# ローカルの main ブランチへ切り替えます
git switch main
# リモートの main ブランチを fast-forward で取り込みます
git pull --ff-onlybash
# ローカルの main ブランチへ切り替えます
git switch main
# リモートの main ブランチを fast-forward で取り込みます
git pull --ff-only5. 統合履歴と Issue を確認する
feature ブランチから develop、develop から main への2段階の統合を確認します。
Agent モードで以下の指示を与えます。
text
全ブランチを含む直近10件のコミット履歴と、「残席が少ないイベントを分かりやすくする」Issue の状態を読み取り専用で確認してください。
feature から develop、develop から main への2段階の統合が履歴で確認できるか、release Pull Request の Closes により Issue が Closed かを要約してください。
候補 Issue が複数ある場合は推測せず質問し、Git や GitHub の状態は変更しないでください。次を確認します。
- feature から
develop、developからmainへの2段階の統合が履歴で確認できる - release Pull Request の
Closesにより対象 Issue が Closed である - 候補 Issue が複数ある場合は推測されていない
- Git と GitHub の状態が変更されていない
powershell
# 全ブランチを含む直近10件のコミット履歴をグラフ表示します
git log --oneline --graph --decorate --all -10
# 演習で作成した Issue の番号を取得します
$issueNumber = (gh issue list --state all --limit 100 --json number,title |
ConvertFrom-Json |
Where-Object { $_.title -eq "残席が少ないイベントを分かりやすくする" } |
Select-Object -First 1).number
# 演習で作成した Issue の状態を表示します
gh issue view $issueNumberbash
# 全ブランチを含む直近10件のコミット履歴をグラフ表示します
git log --oneline --graph --decorate --all -10
# 演習で作成した Issue の番号を取得します
issue_number=$(gh issue list --state all --limit 100 --json number,title \
--jq '.[] | select(.title == "残席が少ないイベントを分かりやすくする") | .number' |
head -n 1)
# 演習で作成した Issue の状態を表示します
gh issue view "$issue_number"- マージ済みの release Pull Request を開き、ベースが
main、ヘッドがdevelopであることを確認します。 - 関連 Issue を開き、状態が Closed であることを確認します。
確認事項
- release Pull Request のベースが
main、ヘッドがdevelopである - release Pull Request の CI と必要なレビューが完了している
- release Pull Request が Merge commit により
mainへマージされ、ローカルのmainが同期している Closes #<Issue番号>の対象 Issue が Closed である- feature ブランチから
develop、developからmainへの2段階の統合を履歴で確認できる
まとめ
develop に統合された変更をリリース単位で確認し、main 向け Pull Request を作成しました。CI、レビュー、関連 Issue、ベース、ヘッドを確認してからマージコミットで統合し、Closes #<Issue番号> によって Issue が自動で閉じることも確認しました。
次は、main へのマージで開始された GitHub Pages Workflow と公開サイトを確認します。