みなさんはGitHubのプルリクエストの機能を使ったことはありますか？ ウェブ制作の場でもGitHubが使われることが多くなったと思いますが、ソースの履歴管理機能のみを使用している方も多いのではないでしょうか？ 今回はGitHubのプルリクエストについて紹介します。普段からプルリクエストを使っている方でも役立つプラスアルファのTipsをまとめていますので、最後までお付き合いください。
プルリクエストとは？
プルリクエストとは、コードの変更をレビュワーに通知し、マージを依頼する機能です。コードのレビューを受けることで、1人で作ると気がつかないコードの指摘やバグや記述ミスの発見ができ、コードの品質を高めます。レビュワーにとっても、他人が書いたコードを読むことで新しい書き方を発見できるというメリットがあります。コードから発展してプロジェクトに関する有意義な議論の場になることもあるでしょう。
プルリクエストを導入した際の流れは次のとおりです。「1. GitHubにブランチをプッシュする」より先の項目はすべてGitHub上で完結でき、難しい操作は必要ありません。
- 開発者がGitHubにブランチをプッシュする
- 開発者がブランチからプルリクエストを作成する
- レビュワーがコードをレビューする
- ブランチをマージする
プルリクエストを送ってみよう
今回は、自分が所属するチームのリポジトリにプルリクエストを送る手順を解説します。親となるブランチに、親ブランチから分岐してできた子ブランチをマージする手順を追ってみましょう。
リポジトリトップからプルリクエストを作成を開始する
まずは、リポジトリのトップ画面で[New Pull Request]ボタンを押して、プルリクエストの作成を開始します。
親ブランチと子ブランチ名を選択する
ブランチ名が書かれたコンボボックスから、ブランチを選びます。左側のブランチに親ブランチ、右側に子ブランチを選択します。
プルリクエストの内容を確認する
コンボボックスでブランチを選択すると、コミット履歴とソースコードの差分が表示されます。選択したブランチに間違いがなければ[Create pull request]ボタンを押して、プルリクエストの詳細を作成する画面へ移動します。
プルリクエストの詳細を決める
最後に[Create pull request]ボタンを押し、プルリクエストの作成を完了します。この画面では、プルリクエストのタイトルと詳細について設定できます。プルリクエストのフォーマットはチーム内で決めるものですが、次の項目を意識するとレビューの観点が明らかになり、後ほどトラブルがあった場合も見直しやすくなります。
タイトル
- 簡潔なタイトルで内容がすぐわかること
詳細
- プルリクエストを送るに至った経緯
- マージすることで期待できる結果
- このプルリクエストでは行わないこと - 対応しない項目に関しての指摘が入らないようにするため
- マージ後のリスク - 修正箇所の影響範囲などを記入することで、デバッグ項目の漏れなどを減らす
- 関連するIssueやURL
その他の設定項目
- Reviewers - レビューする人を設定します
- Assignees - プルリクエストの内容を対応した人・対応する人を設定します
- Labels - [bug（バグ）][question（質問）][enhancement（機能の実装）]等から選択します
- Milestone - マイルストーンを選択します（[Issues]画面の[milestone]ボタンから作成可能）
レビュー機能を活用しよう
プルリクエストの画面では、コードのコミット履歴やファイルの変更箇所が分かりやすく表示され、レビュワーにレビューを依頼できます。
Files Changes画面でレビューを開始
レビュワーは気になるソースコードに対してコメントを書いてフィードバックを送ります。ソースコードの行にマウスカーソルを当てると[+]ボタンが表示されるので、気になる行の[+]ボタンを押し、コメントを記入します。コメントが終わったら、[Start Review]ボタンを押し、レビューを開始します。気になる箇所すべてにレビューが完了したら、[Review Changes]ボタンを押し、[Approve（承認）][Request Changes（変更の要求）][Comment（コメント）]のいずれかを選択し、[Submit review]ボタンを押してレビューを送信します。
▲ [File Changes]画面では、ファイルの変更箇所が分かりやすく表示されている。ソースコードに対してコメントできる。
Conversation画面でレビューを一覧
[Conversation]画面では誰がどこに対してレビューしたかや、レビュワーのレビュー状態を確認できます。レビューが完了し、コードに問題があれば同じブランチに修正したコードをプッシュしてもらい、再度レビューを行います。コードが問題なければ、[Merge pull request]ボタンを押し、ブランチをマージします。
▲ [Converion]画面ではレビュー内容が表示される。どこにレビューが行われたかやレビュー状態を確認できる。
Tips：CONTRIBUTINGファイルでプルリクエストの品質を高める
リポジトリの直下か.githubフォルダー以下にCONTRIBUTINGファイルを作成すると、プルリクエストの新規作成画面にCONTRIBUTINGファイルへのリンクが記載されます。このファイルを作成しておくことで、プルリクエストやIssueを送る際のルールの周知を行えます。
▲ CONTRIBUTINGファイルへのリンクが表示されている。
▲ CONTRIBUTINGファイルの例（Atom）。プロジェクトの概要やコントリビュートする際のルールが記載されている。
Tips：PULL_REQUEST_TEMPLATEファイルで
プルリクエストの定型文を決める
リポジトリの直下か.githubフォルダー以下にPULL_REQUEST_TEMPLATEファイルを用意することで、プルリクエストの新規作成時の初期テキストを設定できます。たとえば、「プルリクエストを送るに至った経緯」「マージすることで期待できる結果」「このプルリクエストでは行わないこと」「マージ後のリスク」「関連のIssueやURL」等の最低減の必要なプルリクエストのテンプレートを作成しておくことで、レビュワーは一定の情報を持ってプルリクエストを受けることができ、不要な質問のやり取りを減らせます。
Tips：タスクリストを作成する
次のフォーマットでプルリクエストの詳細の入力欄に記入すると、チェックボックスを作成できます。ちょっとしたテスト項目など、作業の管理に使うと便利です。
- [ ] 未完了のタスク
- [x] 完了済みのタスク2
まとめ
プルリクエストを導入することで、チーム全体のコードやプロジェクトの理解が高まり、コンテンツの品質を上げることができます。まだ、プルリクエストを使ったことがない人も、この機会にぜひ取り入れてみてはいかがでしょうか？
