GitHub Foundations #5 Domain 3-2: コラボレーション — Pull Request・コードレビュー・Discussions
コラボレーションドメインの後半です。前半がIssueを中心とした作業トラッキングだったのに対し、今回はGitHubコラボレーションの中心手順であるPull Requestとコードレビュー、そしてIssueとよく比較されるDiscussionsを整理します。同じドメインの範囲に含まれるGitHub PagesとWikiも合わせて扱います。この記事は、試験が問う各機能と状態の正確な意味に集中します。PRをチームでうまく運用する実務の観点はGit実務ワークフロー #5 PR運用 — レビュー単位・コミットメッセージ・draft PRで別に扱いました。
Pull Requestのライフサイクル #
Pull Requestは、ブランチの変更を別のブランチへマージしてほしいという依頼であり、その変更をレビューする会話の場でもあります。試験の観点では、ライフサイクルの各段階を正確に知っておく必要があります。
- 作成 — ブランチをpushすると、リポジトリページにCompare & pull requestボタンが現れます。baseが変更を受け取るブランチ、compareが変更を送るブランチです。
- draft — まだレビューを受ける準備ができていないPRは、draft状態で開けます。draft状態ではマージボタンが無効化され、Ready for reviewを押してはじめて正式なレビュー段階に進みます。
- レビュー — レビュアーがコメントを付け、承認するか変更を要請します。
- マージ — 3つの方式のいずれかでbaseブランチに合流します。
- 後片付け — マージされたブランチはDelete branchボタンで削除します。
PRが開いている間、同じブランチにコミットをpushするとPRに自動で反映されます。PRを閉じて開き直す必要がないという点、そしてdraftではマージが塞がれるという点が、よく出題される箇所です。
コードレビュー — レビュアー、CODEOWNERS、レビュー状態3種 #
レビュアーはPRのReviewers欄で直接指定します。リポジトリ単位で自動指定するにはCODEOWNERSファイルを使います。
# パスパターン 所有者
*.js @frontend-team
/docs/ @octocat
/infra/ @org/platform-teamCODEOWNERSは、パスパターンごとにコードの所有者を宣言するファイルで、該当パスに触れるPRが開かれると所有者がレビュアーとして自動指定されます。ファイルの位置はリポジトリのルート、docs/、.github/の3か所のいずれかが許可される、という事実が試験ポイントです。
レビューを提出するときは、3つの状態からひとつを選びます。
| レビュー状態 | 意味 |
|---|---|
| Comment | 意見だけを残します。承認でも反対でもありません |
| Approve | 変更を承認します。マージ要件の承認数に集計されます |
| Request changes | 修正を要求します。解決までマージを塞ぐことができます |
コード行に付けるコメントでは、suggested changes機能で修正案をコードブロックの形で提案できます。作成者は提案を確認し、Commit suggestionボタンで即座にコミットとして反映します。タイポ修正のような小さな変更を往復なしで終わらせる機能です。
PRとIssueの連携 #
PRがどのIssueを解決するのかを結びつける方法は2つあります。
- PR本文にクローズキーワード(
closes #12など)を書きます。前回扱ったとおり、デフォルトブランチにマージされるときにIssueが自動で閉じます。 - PRまたはIssueのサイドバーにあるDevelopmentフィールドで手動で連携します。効果はクローズキーワードと同じです。
連携されたIssueはPRのサイドバーに表示され、Issue側からもどのPRが進行中かが見えます。
Discussions — Issueとの用途の区別 #
Discussionsは、リポジトリに付く掲示板型の会話の場です。試験はIssueとの用途の区別を頻繁に問います。
| 区分 | Issue | Discussions |
|---|---|---|
| 用途 | 作業トラッキング (バグ、機能、タスク) | 会話 (質問、アイデア、告知) |
| 終結 | 解決したら閉じる | 閉じる概念が弱く、回答の採択で締める |
| 構造 | 時系列のコメント | カテゴリー別スレッド、ネストした返信 |
DiscussionsにはQ&A、Ideas、Announcements、Show and tellといったカテゴリーがあり、Q&Aカテゴリーでは質問者が返信のひとつをMark as answerで採択できます。Announcementsカテゴリーは、管理権限のある人だけが新しい投稿を書けます。会話が具体的な作業に発展したら、DiscussionをIssueに転換する機能もあります。整理すると、トラッキングする作業はIssue、結論が開かれた会話はDiscussionsです。
GitHub Pages — リポジトリから静的サイトへ #
GitHub Pagesは、リポジトリのファイルを静的Webサイトとしてホスティングする機能です。コラボレーションドメインの範囲に含まれる試験ポイントです。
- サイトの種類 — ユーザー・組織サイトは
username.github.ioという名前のリポジトリで作り、アドレスも同じです。プロジェクトサイトは任意のリポジトリで作り、username.github.io/リポジトリ名のパスで提供されます。 - 公開ソース — 指定したブランチの指定ディレクトリ(ルートまたは
/docs)からそのまま公開するか、GitHub Actionsワークフローでビルドして公開する2方式があります。静的サイトジェネレーターのJekyllが標準でサポートされます。 - 可視性 — 公開リポジトリでは無料プランで使え、非公開リポジトリのPagesには有料プランが必要です。
Wiki — リポジトリに付く文書スペース #
Wikiは、リポジトリに付く簡単な文書スペースで、コードと分けて説明書や設計文書を積むときに使います。各ページはMarkdownで書き、Wiki自体も別のGitリポジトリとしてcloneできます。文書をコードと同じPRの流れでレビューしたいならWikiよりリポジトリ内のdocs/ディレクトリが向いている、という判断基準まで知っておけば十分です。
マージ3方式の復習 #
マージボタンの3方式はGitトラックですでに扱った内容ですが、試験の観点でもう一度整理します。
- Merge commit — マージコミットを作り、2つの履歴を保存したまま合流させます。
- Squash and merge — PRのすべてのコミットをひとつにまとめてbaseに追加します。PR 1件がコミット1件になります。
- Rebase and merge — PRのコミットをマージコミットなしでbaseの上に順に再適用します。
リポジトリ設定で3方式のうち許可するものを制限できる、という事実も合わせて覚えておきます。
まとめ #
コラボレーションドメインの2回を終えました。PRのライフサイクルとdraftの効果、CODEOWNERSとレビュー状態、IssueとDiscussionsの区別、Pagesの2つの公開ソースが今回の核心です。
次回の「GitHub Foundations #6 Domain 4: モダン開発 — Actions・Codespaces・Copilot・Packages」では、GitHubを開発プラットフォームへ拡張する機能を扱います。特にgithub.devとCodespacesの違いは試験の定番なので、表で正確に比較します。