プルリクエストとマージ——完成した作業をまとめる

プルリクエストは変更の提案

前の記事では、mainから作業ブランチを分け、そこで変更を進める方法を学びました。作業がある程度まとまったら、「この変更をmainに取り込みたい」と提案できます。GitHubでその提案をまとめる仕組みが、プルリクエストです。

PRには何が入る？

英語の Pull Request を短くして「PR」とも呼びます。たとえば、りんがAIページの見出しを直した場合、見出し修正の作業ブランチを提案元に、mainを取り込み先としてPRを作れます。PRには、変更の説明や差分、確認結果などをまとめられます。

作っただけでは取り込まれない

ここで大切なのは、PRを作っただけでは、mainへの取り込みは完了しないことです。PRはまず「この変更を取り込みたい」という提案。確認や必要な手続きを経て、マージという別の操作を行うと、取り込み先に変更が入ります。

Gitのpullとは別

「プル」という名前から、第5記事で学んだ `pull` と同じ操作に見えるかもしれません。しかし、プルリクエストはGitHub上で変更を提案・確認する仕組みです。Gitの `pull` コマンドそのものと同じ意味ではありません。

PRを必ず使わなければGitの変更をまとめられないわけではなく、運用方法はサイトやチームによって異なります。コツエイゴでは、まとめて反映する指示があるときに対象を整理し、PRを作って確認する運用です。

報告では提案元と取り込み先を見る

ChatGPTから「PRを作成しました」と報告されたら、URLとあわせて、どのブランチからどのブランチへの提案かを聞きましょう。URLは提案を開くための場所であり、作成されたことだけでマージ済みや公開済みを意味しません。

PRの画面は、変更を説明するメモと、何が変わったかを確かめる資料を一緒に置く場所として考えると分かりやすいでしょう。提案の状態を見ながら、質問や修正を重ねられます。

なるほど！ まずは何が起きているか、ひとつずつ確かめればいいんだね。

PRで何を確認する？

PRを開くと、何を変更したかの説明や、変更前後の差を示す「差分」を確認できます。GitHubでは `Files changed` などの画面で、変更されたファイルや内容を見られます。表示名や画面は変わることがあります。

依頼との違いを見る

記事の見出しを直したPRなら、「頼んだ見出しが変わっているか」「依頼と関係のない内容が混ざっていないか」を確認します。コードが読めなくても、ChatGPTに「画面に見える変化を先に説明して」と頼めば、確認を始められます。

確認結果を読む

テストやビルドの結果も手掛かりです。テストは決められた条件で動作やデータを確かめること、ビルドはサイトを動かすためのファイルを作る工程です。GitHub Actionsなどで自動実行される場合もあります。

ただし、成功の表示があっても、確認していない内容まで保証されるわけではありません。「どのページを、どの幅で確認した？」「実行していない確認は？」と、成功・失敗・未確認を分けて聞きましょう。

修正が必要な場合

変更に気になる点があれば、PR上のコメントやChatGPTへの追加指示で修正を頼めます。作業ブランチに新しいコミットをpushすると、同じPRに変更が追加される場合があります。そのときは、最終的な差分と確認結果をもう一度見ます。

サイトの設定によっては、マージ前のレビューやテスト成功が必須の場合もあります。条件や権限はプロジェクトごとに違うため、満たされていない場合は理由を確認し、必要な手順を守りましょう。

マージは変更を取り込むこと

マージは、あるブランチで進めた変更を、別のブランチへ取り込むことです。たとえば見出し修正の作業ブランチをmainにマージすると、その修正がmain側にも入ります。

PRとマージは別の状態

PRは提案と確認の場、マージは取り込みの操作です。「PRを作成した」「確認した」「mainにマージした」は別々の状態として読みましょう。マージの方法にはいくつか種類がありますが、ここでは名前をすべて覚える必要はありません。

衝突が起きることもある

変更がうまく重ならない場合、衝突（コンフリクト）が起き、調整が必要になることもあります。別の作業の内容を消さないよう、どこで衝突しているかを確認し、必要な変更を残してから進めます。詳しくは次の記事で扱います。

mainに入った後の公開を確認

そして、mainへのマージと本番公開は同じではありません。mainが更新されたら自動的に公開する設定もあれば、別の公開操作が必要なサイトもあります。実際に読者の画面が更新されたか、サイトごとの仕組みに沿って確認しましょう。

たとえば「PRをマージしました。本番公開はまだです」という報告は矛盾しません。一方「マージをきっかけに自動公開されました」となる運用もありえます。報告に書かれていなければ、公開の状態を推測せず尋ねます。

PRの提案元と取り込み先が想定どおりかも確認します。mainに入れるつもりで別のブランチを選んでいた場合、マージはできても目的の場所には入りません。「どこからどこへ取り込んだ？」と聞いてみましょう。

例えば記事の文章だけを取り込むつもりなら、画像や別記事の変更が同じ提案に含まれていないかを確認します。想定外の変更が見つかったときは、削除する前にその理由と他の作業への影響を聞きましょう。

Draft PRは作業途中を示す

作業がまだ完成していない段階で、途中の内容を見せたり相談したりしたいことがあります。GitHubの Draft PR（ドラフトPR） は、そうした作業途中の状態を示すプルリクエストです。

Draftのままではマージできない

Draft PRは、そのままではマージできません。準備が整ったら、レビュー可能な状態へ変更し、必要な確認や条件を満たしてから取り込みます。ドラフトを解除しただけで、自動的にmainへ入るわけではありません。

途中の状態を聞く

「Draft PRを作成しました」と報告されたら、「どこまで完成した？ 残りは何？」「レビューやマージは可能な状態？」と聞くと状況を把握しやすくなります。PRのリンクがあることと、作業が完成したことは別です。

自動検査が動く場合もある

また、Draft PRでも設定によってGitHub Actionsの検査が動くことがあります。作成や追加のpushが必ず無料・無実行とは限りません。無駄を減らしたい場合は、そのリポジトリの実行条件を調べ、必要な検証は保ったまま進めましょう。

どこまで依頼するかを伝える

ChatGPTへの依頼では「PRまで作って、mainにはまだ反映しない」「内容を確認してから公開したい」のように、どこで止めたいかを伝えられます。実際に何をしたかは、PRの状態と報告で確かめます。

ここまでを並べると、作業ブランチに変更を保存し、必要に応じてPRで提案・確認し、マージしてmainに取り込み、サイトの仕組みに応じて公開します。それぞれが別の段階だと分かれば、報告を落ち着いて読めます。