Yuya Karubeさん
  • コラボレーター
  • SELECK(How to)
  • Yuya Karube

チーム開発を変える「GitHub」とは?〜Pull Requestの使い方〜【連載第2回】

  • -
  • このエントリーをはてなブックマークに追加
    -
  • tweet

リポジトリ管理サービスGitHubの入門記事、前回はGitHubへの登録と、Gitの簡単な使い方まで解説しました。今回は、GitHubの目玉機能でもあるPull Request(プルリクエスト)機能について解説します。

今回の内容

  • コードレビューを効率化するPull Requestとは
  • Gitのブランチ(branch)機能とは
  • Pull Requestの使い方
  • コードレビュー時の注意点

次のような方におすすめです。

  • Pull Requestは聞いたことあるけどよく分からない
  • チームでコードレビューを始めてみたい
  • 第1回目よりも進んだGitの使い方を勉強したい

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

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

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

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

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

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

Gitのブランチ機能とは

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

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

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

ブランチはを作ると並行開発が可能

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

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

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

git branch [ブランチ名]

git branchコマンド

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

git checkokut [ブランチ名]

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

git checkoutコマンド

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

ファイルを変更してコミット

ここで一旦、元のブランチ(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 [ブランチ名]

git pushコマンド

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

Pull Requestの作成ボタン

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

Pull Request作成フォーム

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

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時代の開発哲学

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

  • -
  • このエントリーをはてなブックマークに追加
    -
  • tweet