◀ 用語一覧
NO.8.8

🔀 Pull Requests

更新: 2026.09.11

一言で

コードを書くとき、ブランチの切り方とマージの仕方 は複数ある。本章で主要な流儀を見ていく。

どの流儀でも、マージするときは誰もが Pull Request を通す。その中身を解説し、これらは Ruleset で設定・強制できることも押さえる。

ブランチ戦略

PR を中心にブランチをどう構成するか。リリース頻度に合った方式を選ぶ。

戦略仕組み向いているケース
🌿 GitHub Flowmain 1 本 + 短命な feature ブランチ。PR → マージ → main からデプロイ継続的デリバリー・多くのチーム
🌳 Git Flowmain + 長命な develop、加えて feature / release / hotfix定期・バージョン付きリリース

💡 速度重視なら GitHub Flow を既定に。Git Flow はバージョン付きリリース時のみ。

GitHub Flow

長命なブランチは main 1 本、feature ブランチは短命。 main から枝を切り、PR を出してレビュー・マージし、そのままデプロイ。シンプルで速く、頻繁にデプロイする Web アプリや小規模チームに最適。

change main change change
  • 🌿 変更ごとに main から枝を切る（feature / fix）
  • 🔀 早めに PR を出す — レビューと CI はブランチ上で
  • ✅ main にマージ → 即デプロイ
  • ♻️ main は常に デプロイ可能 に保つ

💡 部品が少ない＝フィードバックが速い。継続的デリバリーの既定。

Git Flow

長命なブランチは main + develop の 2 本、加えて補助ブランチ。 作業は develop に統合し、release ブランチでバージョンを安定させてから main へマージしてタグ付け。定期的なバージョンリリースや大規模チーム向けの構造化フロー。

main hotfix release develop feature feature v0.1 v0.2 v1.0
  • 🌳 develop = 統合ライン・main = 本番（タグ付き）
  • 🧩 feature/* は develop から切って戻す
  • 📦 release/* で安定化 → main + develop へマージし、バージョンを タグ
  • 🚑 hotfix/* は main から切る緊急の本番修正 → 両方へマージ

🎯 手順は多いが制御は強い。継続デプロイではなく バージョンリリース を出すならこれ。

レビューの中身

今日、PR を開くのは 人間・Cloud Agent・Dependabot・Agentic Workflow と多様になった。差分の上に会話・チェック・自動分析が集まり、マージ前に品質を担保する場。

要素役割
🔀 差分提案branch を比較してマージ依頼
💬 レビュー行単位コメント・承認/却下
🤖 Copilot コードレビューPR ごとに AI が自動レビュー
✅ テスト / CIstatus check の通過を必須に
🛡️ Code Scanning（GHAS・Code Security）CodeQL でセキュリティ脆弱性を検出
📊 Code Quality（独立プロダクト）保守性・信頼性を分析（GHAS とは別課金）

🔑 PR で Closes #123 → マージで Issue 自動クローズ。

Ruleset

Ruleset は、ブランチへのマージ条件を ルールとして強制 する品質ゲート。Organization レベルでも repository レベルでも設定でき、上位から横断適用もできる。

最小構成の推奨:

ルール推奨設定目的
🔀 Require a pull request before mergingON ＋ Required approvals: 1直 push を禁止し、必ず 1 名以上のレビューを通す
🛡️ Require status checks to passtest を必須 ＋ Require branches to be up to date before mergingCI が緑、かつ最新の main に対して検証されたときだけマージ
🔍 Require code scanning resultsCodeQL の結果を必須（重大度でブロック）未解決のセキュリティ脆弱性があるとマージを止める
🔒 Block force pushesON履歴の破壊的な上書きを防ぐ
🤖 Automatically request Copilot code reviewONPR ごとに Copilot が自動で先行レビュー

🎯 個別の手運用をやめ、Ruleset で「上から一括」ゲート。

Stacked pull requests（NEW） 📖 Docs

各 PR が 1 つ下の PR のブランチを base にする、順序付きのチェーン。レビュアーは巨大な差分ではなく、小さなレイヤーを 1 枚ずつ見ればよくなる。public preview は 2026-07-30 から。

スタックのマージは不可分な 1 回の操作。main に何が入るかはマージ方法で変わる:

feat-c feat-b feat-a main base: feat-b base: feat-a base: main マージコミット 1 つ (PR #1-3)

ブランチのコミットはそのまま残り、スタック全体が 1 つのマージコミットで入る。履歴は最も詳しい。

feat-c feat-b feat-a main base: feat-b base: feat-a base: main PR #1 PR #2 PR #3

PR ごとに 1 コミットへまとめて main に載せる。ログは最もきれいだが、個々のコミット（淡色）は失われる。

feat-c feat-b feat-a main base: feat-b base: feat-a base: main PR #1 PR #2 PR #3

すべてのコミットを順に main へ載せ直す。マージコミットのない直線的な履歴になる。元のコミット（淡色）は書き換えられる。

  • 🧱 ブランチ保護と CI は すべてのレイヤー で動く。一番下の PR だけではない
  • 🔄 rebase は GitHub 任せ — 下のレイヤーをマージすると、上の PR は自動で base を張り替える
  • ☝️ 1 つ・一部・全部 から選べる。一番上の PR をマージすればスタック全体が下から順に入る
  • 🛠️ github.com / Mobile / REST・GraphQL・webhook、そして gh extension install github/gh-stack

Agent merge（NEW）

GitHub Copilot app で、PR の最後の一押しをエージェントに任せる。マージを塞いでいるものを片付け、GitHub が許可した時点でマージする。

  • 🔀 PR の上部でトグルを ON — そのワークスペースの Copilot セッションが引き受ける
  • 🩹 塞いでいるものを直す：レビューコメント、失敗した check、コンフリクト
  • 🌙 バックグラウンドで動作 し、アプリを再起動しても継続する
  • ✅ マージが完了すると 自動で OFF になる

⚠️ ゲートは迂回しない。main に入るものを決めるのは、これまで通り required approvals と required checks。

★ AI 時代の PR

AI が PR を量産する今、「PR はもう要らない?」の声もある。だが repo を理解可能で安全に保つには、このゲートが必要。

  • 🤖 Copilot が自動レビューで指摘を先回り
  • 📈 2026 年は月 90M マージ (約 2x)
  • 👀 人は最終承認、AI は下準備

💡 PR を守りつつ速くする = Ruleset × Copilot。