コードレビューを効率化するPull Requestとは

チーム開発をするうえで、コードの品質を保つためにもコードレビューを実施している会社は多いでしょう。そのコードレビュー、どのような形で実施されていますか？

全員で集まって一つの画面でコードを確認したり、気になる部分だけを人に聞いてみたり、はたまたメーリングリストを使ってみたり。

しかし、そういった方法では、自分が気になっているポイントしか見てもらえない、レビューの結果が残りづらい、一部の人しかコードを見れないといった問題点が出てきます。そんな問題を抱えているチームも、GitHubのPull Request機能を使えば、効率的で効果的なコードレビューを実践できるようになります。

それではPull Requestの使い方を見ていきましょう。

Gitのブランチ機能とは

Pull Requestを学ぶ前に知っておくべきものに、Gitのブランチ(branch)という概念があります。ブランチ機能を上手く活用すると、例えば新規機能開発とバグ修正といった複数の作業を、並行して進められるようになります。

もしブランチ機能のないバージョン管理システムだと、一度新規機能の実装を始めてしまうと簡単なバグでも修正することが難しくなってしまいます。新規機能の実装分がコードに反映されているため、バグを修正したとしても中途半端な状態となり、リリースができないのです。

ブランチは、簡単にいうと作業ディレクトリの複製です。ただ複製するだけでなく、最終的に複製前のブランチに変更点を統合できます(これをマージと言います)。

ブランチ機能を使ってみる

では早速、ブランチを作ってみましょう。まだGitHubでレポジトリを作っていない人は、まずは前回の記事を参考にしてレポジトリを作りましょう。

ブランチを作成するには、git branch test-branchコマンドを使用します。これでtest-branchという名前のブランチが作られます。git branchコマンドで、存在するブランチの一覧を確認できるので、正しく作れたかの確認も合わせて行いましょう。

git branch [ブランチ名]

ブランチが作成できたら、git checkout [ブランチ名]で作業するブランチを切り替えます。コマンドを打った後、git branchコマンドでブランチが切り替わっているか確認できます。

git checkokut [ブランチ名]

▼現在のブランチは表示が変わる

これだけではブランチのメリットはあまり理解できないので、ファイルを編集してコミットしてみましょう。コミットの手順は前回の記事を参考に。

ここで一旦、元のブランチ(master)に戻してみましょう。git checkout masterコマンドを実行します。すると、先ほど修正したファイルが修正前の状態に戻っているはずです。これは、先ほどの修正がtest-branchブランチにコミットされたため、元のmasterブランチにはまだ反映されていないからです。

もう一度git checkout test-branchを実行してみましょう。すると、作業ブランチがtest-branchに戻り、先ほどの編集内容が残っているはずです。この仕組みを利用して、例えば時期バージョン用のブランチで新規開発を進め、元のブランチはバグfixのみを行うという並行開発が実現できます。

Pull Requestの作り方

それではブランチができたところで、Pull Requestの解説に入っていきましょう。Pull Requestは、「編集リクエスト」のような機能です。こういう修正をしてみたけど、もし良ければ反映して下さい、というものです。

先ほど「branchにコミットした修正を元のbranchに反映できる」と説明しましたが、Pull Requestはまさにこの機能を利用しています。企業で一般的に使われるPull Requestの流れをまとめると、次のようになります。

1. 自分が担当する実装用の、branchを作成する
2. 変更点をコミット
3. そのbranchを元にPull Requestを作成する
4. レビュアーはPull Reqeustを確認し、問題なければ元のブランチに反映(マージ)する

(2)までの方法は前章までに解説したので、ここでは(3)から解説していきます。

まず、先ほど作成したbranchはローカルにしか存在しないため、皆が見れる場所(GitHub上のリモートリポジトリ)にプッシュします。ブランチをプッシュするには、git push -u origin test-branchコマンドを使います。

git push -u orgin [ブランチ名]

そしてこのコマンド実行後にGitHubのリポジトリページを見ると、次のような表示が出ているはずです。

ここで[Compare & pull request]を選択します。すると、Pull Requestの作成ページに飛びます。修正点を一言で表すようなタイトルを付け、実装内容や補足をコメント欄に書いて、[Create pull Request]ボタンを押します。これでPull Requestの作成は完了です。このような画面になったらOKです。

そのPull Requestでどのような差分があるのかを確認したいときは、[Files changes]タブを開きます。

Pull Requestを活用したレビューの方法

あとは、このPull RequestのURLをレビュー担当者に渡すなり、チャットツールと連携して通知を飛ばすなりして、レビューを依頼します。[Conversation]タブからコメントを残していけるので、疑問点や指摘はどんどん書いていきましょう。

また、コメントには絵文字でリアクションが付けられます。コメントに対して「+1」絵文字で同意を伝えたり、まあその他の絵文字の使いドコロは分かりませんが、和気あいあいとした感じを醸し出せます。殺伐としたレビューのやり取りも、絵文字で和むことでしょう。

もし、あるコードの具体的な箇所に対して指摘をしたい場合は、[Files changed]タブから、コードの行を指定してコメントを挿入できます。もちろん本来のコードにコメントを差し込むわけではなく、GitHub上の話なので安心してください

レビューが完了したら、そのブランチをマージ(merge)して、元のブランチに変更を反映します。[Merge pull request]をクリックし、[Confirm merge]を選択します。

これでPull Requestの一連の流れは完了です。GitHubのレポジトリのトップに戻ると、先ほど反映した修正がmasterブランチに反映されているのが分かるはずです。

コードレビュー時の注意点

ここまでで、Pull Requestで行うコードをレビューの解説は終わりです。すでに会社でGitHubを使用されている場合は、細かいやり方が違ってくると思うのでそこに合わせ、まだ取り入れていない場合は、他社の事例を調べながら自社なりのフローを作ると良いでしょう。

コードレビューで気をつけるべき点は、Pull Requestで便利になると言えどレビューをするのは人だということです。人と人のコミュニケーションに他ならないので、指摘の目的を正しく伝えるための決まりを作ったり、オフラインのコミュニケーションも合わせてレビューをスムーズに進めましょう！

他にはコードの意図が分からなかった時は「Question」を付けたり、「+1」を付けて書き方を褒めるということもしています。このレビューは何を伝えたいのか、というルールを統一することで間違った伝わり方をすることもなくなりますし、誰がいつ入ってきてもスムーズにチーム開発を進められる仕組みができています。

GitHubでコードを「公開しない」リスク？サイバーエージェント流、OSS時代の開発哲学

▼このシリーズの記事一覧

• チーム開発を変える「GitHub」とは？導入方法・使い方を徹底解説！【第1回】【導入編】
• チーム開発を変える「GitHub」とは？〜Pull Requestの使い方〜【連載第2回】
• チーム開発を変える「GitHub」とは？〜Issuesの使い方〜【連載第3回】
• チーム開発を変える「GitHub」とは？〜Organizationとアクセス管理〜【連載第4回】
• チーム開発を変える「GitHub」とは？〜ZenHubでカンバンを使う〜【番外編】
• GitHubライクな機能が備わったOSS「GitLab」とは？【GitHub入門】【第5回】
• GitHubがより便利になる使い方、ショートカット・Trending・gitterを解説【連載第6回】
• GitHub Enterprise、GitLab、BitBucket。GitHubライクなサービス3つの特徴を紹介【連載第7回】