前回は、READMEを直接書き換えて記録しました。記録するときに出てきた選択肢のうち、1つ目の「Commit directly to the main branch」を選んだのを覚えているでしょうか。今回は、残しておいた2つ目の選択肢を使います。
2つ目の選択肢から始まるのが、プルリクエストという仕組みです。会社の仕事にたとえると、稟議や回覧に近いものです。修正案を書いて回し、確認してもらい、了承を得てから正式版に反映する。紙やメールでやっている流れを、GitHubの上でそのまま行えます。
先に覚えておく3つの言葉
今回の手順には、新しい言葉が3つ出てきます。
| 言葉 | 意味 | 仕事にたとえると |
|---|---|---|
| ブランチ | 本体（main）から枝分かれさせた、作業用の写し | 原本をコピーした「修正案の下書き」 |
| プルリクエスト | ブランチの変更を本体に取り込んでほしい、という申し出 | 「この修正でよいですか」と回す稟議書 |
| マージ | ブランチの変更を本体に取り込むこと | 承認された修正を原本に反映すること |
図にすると、こうなります。本体から枝分かれして修正案を作り、確認が済んだら本体に合流させます1。
ブランチで作業している間、本体のmainは元のままです。確認が終わるまで、正式版には何も影響しません。
修正案を出す
第3回で作った work-notes リポジトリのREADMEに、1文足してみます。
READMEを開き、鉛筆のマーク（Edit file＝ファイルを編集）を押します。最後の文の下に空行を1つ入れてから、新しい文を書き足してください。書き終えると、全体はこうなります。
# 業務メモ
このリポジトリでは、業務手順と変更履歴を管理します。
修正するときは、プルリクエストで提案します。
空行を入れずに改行だけで書き足すと、Previewで前の文とつながって、1つの段落に見えてしまうことがあります。文と文の間には、空行を1つ入れておくのが確実です。
書き終えたら「Commit changes...（変更を記録する）」を押します。ここまでは前回と同じです。違うのは、記録先の選択です。
- Commit directly to the main branch（mainにそのまま記録する）
- Create a new branch for this commit and start a pull request（新しいブランチを作って、プルリクエストを始める）
今回は2つ目を選びます。ブランチの名前は「アカウント名-patch-1」のような形で自動で入るので、そのままで構いません。コミットメッセージは「READMEに運用ルールを追加」としておきます。
2つ目を選ぶと、下のボタンが「Propose changes（変更を提案する）」に変わります2。これを押します。
記録先で2つ目の選択肢を選ぶと、ボタンが「Propose changes」に変わる
次に「Open a pull request（プルリクエストを開く）」の画面が出ます。ここでタイトルと説明を書きます3。
タイトルは「READMEに運用ルールを追加」。説明欄には、何を変えたかに加えて、なぜ変えるのかを書きます。たとえば、こんなふうにです。
READMEに、修正はプルリクエストで提案するという運用ルールを1文追加します。
修正をいきなりmainに入れず、確認してから取り込む流れを、READMEに明記しておくためです。
第3回の最後に、「理由を書き残すのは、人の仕事」と書きました。その理由を書く場所が、まさにこの説明欄です。何を変えたかは、差分を見ればある程度分かります。でも、なぜ変えたのかは、書いておかなければどこにも残りません。
書けたら「Create pull request（プルリクエストを作成）」を押します。
画像② 説明欄には、何を変えたかに加えて「なぜ」を書く
プルリクエストの画面を見る
プルリクエストができると、専用の画面が開きます。上にいくつかタブが並んでいますが、今回使うのは2つだけです4。
- Conversation（会話）：説明、コメント、これまでの経緯が時系列で並ぶ
- Files changed（変更されたファイル）：変更前と変更後の差分
Files changed の見方は、第3回で見た履歴の差分と同じです。消えた行は赤と「-」、加わった行は緑と「+」で表示されます。今回は、追加した空行と文章が緑で表示されます。
行にコメントして、直して、解決する
実際の仕事では、ここで同僚や上司が修正案を確認します。今回は一人なので、自分で確認役も務めてみましょう。
Files changed のタブで、追加した行にマウスを重ねると、行番号の横に青い「＋」が出ます。これを押せば、その行に直接コメントを書ける仕組みです5。書いたら「Comment（コメントする）」を押します。たとえば、こんなコメントです。
「確認してから取り込む」ことも、この1行で分かるようにしたいです。
画像③ 変更した行そのものにコメントを付けられる
コメントを受けて、修正案を直します。プルリクエストを作り直す必要はありません。修正案を書いているブランチのREADMEを、もう一度編集します。
- プルリクエストの画面の上のほうに、「main from （作業ブランチ名）」と表示されています。「from」の後ろにある名前（例：signal-yield-patch-1）を確かめておきます。
- リポジトリの「Code（コード）」タブを開きます。
- 左上の「main」と書かれたブランチ選択のボタンを押し、さっき確かめた作業ブランチの名前を選びます。
- README.md を開き、鉛筆のマークで編集画面に入ります。
最後の文を、次のように書き換えます。
# 業務メモ
このリポジトリでは、業務手順と変更履歴を管理します。
修正するときは、プルリクエストで提案し、確認を受けてから取り込みます。
「Commit changes...」を押すと、記録先の1つ目が、mainではなく作業ブランチの名前になっているはずです。それを選び、コミットメッセージは「READMEの運用ルールを具体化」とします。同じブランチに記録すれば、この修正はそのままプルリクエストに加わります。
直し終えたら、コメントを解決済みにします。修正したあとの Files changed では、元のコメントに「Outdated（古い）」の印が付き、差分の行の下には表示されなくなります。慌てずに、右上にある吹き出しのアイコンを押してください。コメントの一覧が開くので、未解決（Unresolved）のコメントにあるチェックの形のアイコンを押します。これが「Resolve conversation（会話を解決済みにする）」です5。指摘に対応した、という印になります。解決済みにしたコメントは折りたたまれますが、消えるわけではありません。どんな指摘があり、どう直したのかは、あとから開いて読めます。
画像④ 修正後は右側のコメント一覧を開き、チェックの形のアイコン（Resolve conversation）を押す
マージして、本体に取り込む
確認が終わったら、修正案を本体に取り込みます。
本来は、ここで別の人が承認（Approve）してからマージします。ただ、自分で出したプルリクエストは、自分では承認できません6。承認を必須にする設定をしていない練習用のリポジトリなら、自分で確認してそのままマージできます。
マージの方法はいくつかありますが、今回は「Create a merge commit（マージの記録を作る）」を使います。Conversation のタブに戻り、下のほうにある「Merge pull request（プルリクエストをマージ）」を押してください。ボタンの表示が違うときは、横のメニューから「Create a merge commit」に切り替えます。確認の画面が出るので、「Confirm merge（マージを確定）」を押せば完了です7。
画像⑤ 「Merge pull request」を押し、「Confirm merge」で確定する
マージが済むと、「Delete branch（ブランチを削除）」のボタンが出ます8。役目を終えた作業用の写しを片付けるボタンです。消すのは不安かもしれません。でも、修正の中身や記録は、すでに本体に取り込まれています。プルリクエストの画面も、説明やコメントごと残ったままです。必要になれば、同じ画面の「Restore branch（ブランチを復元）」で戻すこともできます。
最後に、第3回と同じようにREADMEの「History（履歴）」を開いてみましょう。
画像⑥ ブランチで行った修正が、本体の履歴に加わっている
「READMEに運用ルールを追加」と「READMEの運用ルールを具体化」。最初の修正と、コメントを受けた修正が、本体の履歴に並んでいます。リポジトリ全体の記録の一覧には、「Merge pull request」で始まるマージの記録も加わります。どの修正が、どの確認を経て本体に入ったのか。プルリクエストの画面と合わせて見れば、たどれるようになりました。
つまずきやすいところ
うっかり1つ目の「Commit directly to the main branch」を選んでしまっても、慌てなくて大丈夫です。記録はきちんと残っています。内容を直したいときは、次の修正をプルリクエストで出し直せば済みます。mainへの直接の記録そのものを禁止する設定もありますが、非公開リポジトリで使うには有料プランが必要です9。
自分で出したプルリクエストに承認（Approve）のボタンが見当たらなくても、故障ではありません。承認は、本来は別の人が出すものだからです6。ただし、承認やチェックを必須にする保護の設定をしたリポジトリでは、持ち主であっても、条件を満たすまでマージできないことがあります9。
今回の方法（Create a merge commit）でマージすると、記録の一覧に「Merge pull request #（番号） from…」という記録が1つ増えます7。番号は、そのリポジトリで何番目のプルリクエストかを表します。自分で書いた覚えのない記録が出てきて驚くかもしれませんが、「ここで修正案を本体に合流させた」という印です。
修正する前のコメントの下には、「Resolve comment」というボタンも出ています（画像③）。こちらを押しても解決済みにできますが、今回の流れでは、直してから解決するのがおすすめです。直したあとはコメントが行の下から消えたように見えますが、なくなったわけではありません。右上の吹き出しのアイコンから開けば、ちゃんと残っています。
佐藤さん(仮名）の会議前を、もう一度
第1回で、営業企画部の佐藤さんの「会議まであと10分」の場面を描きました。後半の「仕組みがある状態」では、佐藤さんは変更案を昨日の版と比べ、集計条件の行まで書き換えられていることに気づきます。そして「集計条件は昨日の版のままにしてください」とコメントを残し、この案はまだ取り込まないと決めました。
種明かしをすると、あの場面はプルリクエストでした。
AIが作った修正は、ブランチの上の修正案として届いていました。佐藤さんが見ていた「変わった行」は、Files changed の差分です。コメントは行へのコメントで、「まだ取り込まない」という判断は、マージしないという選択でした。本体のmainは、昨日確かめた状態のまま。だから会議では、確かめ済みの版を自信を持って使えたわけです。
同僚の田中さんが進めていた日付の修正も、同じ考え方で扱えます。佐藤さんの修正案とは別のブランチで作り、別のプルリクエストとして出す。そうすれば、修正ごとの差分と経緯をたどれます。
ここで大事なのは、仕組みが計算を直してくれたわけではない、という点です。プルリクエストは、修正の中身が正しいかどうかを判断してはくれません。してくれるのは、何が変わったのかを見える形にして、取り込む前に人が確かめる場所を作ることです。判断するのは、最後まで人です。
AIに道具を作ってもらう場面は、これから増えていくはずです。AIの道具の中には、修正をプルリクエストの形で出してくるものもあります。GitHubのAI機能（Copilot）にも、作業を頼むと下書きのプルリクエストを開いてくれる機能があります10。修正が人から届いても、AIから届いても、受け取る側がやることは同じ。差分を見て、気になる行にコメントし、納得してから取り込む。今回の手順そのものです。
第1回で、連載の仮説として「変更を管理する基本は、かつてのExcelのように、ビジネスパーソンの技能のひとつになるのではないか」と書きました。コードを自分で書けなくても、出てきた修正案を読み、受け入れるかどうかを判断することはできます。プルリクエストは、その判断をする場所です。今回の練習で、その手触りを少しでも感じてもらえたならうれしいです。
まとめと次回予告
今回分かったことは3つです。
- 本体を直接書き換えず、ブランチで修正案を作れる
- プルリクエストで、理由を書き、行ごとに確認し、直してから取り込める
- マージしたあとも、修正と確認の経緯は記録に残る
次回は、Issue（イシュー）を使います。「ここを直してほしい」という依頼そのものを記録しておく場所です。依頼から修正、確認、取り込みまでが一本の線でつながる様子を見ていきます。