プルリクエスト

クラス文集に原稿を出す瞬間

クラス全員で文集を作るところを想像してみてください。完成間近の原稿の束が、職員室の机の上にたった1部だけ置かれています。もし30人のクラスメイトが各自赤ペンを持ってその1冊に一斉に書き込んだら、誰がどこを直したのか分からなくなり、大混乱になってしまいますよね。

だから普通はこうします。原稿をコピーして自分用の控えを作り、そこだけに修正を書き込みます。そして修正が終わったら、編集委員にそのコピーと一緒にメモを渡すのです。

メモには「3ページの第2段落の誤字を直しました」のように、どこをなぜ変えたのかを書きます。編集委員はそのメモを見て変更箇所だけを確認すればいいので、ずっと作業が楽になります。プログラムを共同開発するときにも、これとまったく同じようなメモをやり取りします。それがまさに「取り込みの提案書」です。

英語の頭文字をとって「PR（ピーアール）」と略して呼ぶことも多く、使うツールによっては「マージリクエスト」と呼ばれることもあります。呼び方は違っても役割は同じです。

なぜ直接直さずに「提案」するのか？

最大の理由は、第三者の目が加わるからです。自分の修正が元のプログラムに取り込まれる前に、チームの仲間が内容をチェックします。このプロセスを「コードレビュー」と呼びますが、文集でいえば編集委員が原稿を校正・確認する作業にあたります。

2つ目の理由は「記録」が残ることです。提案書を見れば変更された行が一目で分かり、交わされたやり取りもそのまま残ります。数か月後に「どうしてここをこう直したんだっけ？」と疑問に思ったときも、当時のメモを見返せばすぐに理由が分かります。

3つ目の理由は「安全性」です。提案が承認されるまで、元の原稿はきれいな状態のまま保たれます。自分のコピーの中でどれだけ大規模な書き直しをしても、他の人の作業を邪魔することはありません。

そのため、企業の開発でもオープンソースのプロジェクトでもこの方法が広く使われています。初対面の人であってもコピーを作って修正し、メモを提出すれば、管理者がそれを確認して採用するかどうかを判断できます。「見知らぬ人からの協力も安全に受け入れられる仕組み」なのです。

少し正確に言うと：メモ自体は原稿ではない

もう一度文集のたとえに戻りましょう。編集委員に渡したメモ自体は原稿そのものではありません。「このコピーを読んで取り込んでください」というお願いと、そのお願いについて話し合う「コミュニケーションの場」にすぎません。

正確に言うと、提案書とは「修正内容をもとに話し合うチャットルーム」のようなものです。実際に修正したコードは自分のコピーの中にあり、プルリクエストはそのコピーを指し示しながらレビューや会話を行う窓口の役割を果たします。そのため、提案書を開いたまま自分のコピーにさらに修正を加えると、その内容も自動的に反映されます。

もう1つ押さえておきたい点があります。提案を出したからといって、必ず取り込まれるとは限らないということです。読んだ担当者から再修正をお願いされることもありますし、方向性が合わなければそのまま取り下げられる（クローズされる）こともあります。