これだけは押さえておきたいGitHub Flowの基礎

連載第三回は「これだけは押さえておきたいGitHub Flowの基礎」と題して、GitHubを使う上での基本的な部分について解説したいと思います。

と言っても、Git自体の利用方法については既に書籍もたくさんありますし、Web上にも記事が多数ありますので、ここでは特に触れないことにします。これからGit自体を学習する場合に有用なリンク集は、下記のブログ記事にまとめてありますので参考にしてください。

GitHubのトレーニングに役立つリンク集

今回のこの記事では、GitHub Flowについて解説します。

GitHub Flowについて改めておさらい

GitHub Flowというのは、GitHub社が提唱している効果的なワークフローのことです。この言葉は2011年に発表されたこの記事が起源だと思います。

当時Web上で話題になったGit Flowというワークフローに対して、もう少し簡単で理解しやすいワークフローとして提案したのが最初です。

最初のブログ発表から数年たち、内容もだいぶ洗練されてきました。現在では簡単なガイドをWeb上に公開しています。英語ではありますが、これを読むと大枠が理解できるかと思います。

また、1年ほど前にGitHub社のエンジニアブログにGitHub FlowをGitHubでは現在ではどのように実践しているかも解説しました。こちらもぜひご覧ください。

GitHub Flow実践にあたっての要点は下記にまとめることができます。

• masterブランチは常に本番環境へデプロイ可能にする
• 開発を始める際にはまずブランチを作成する(ブランチ名は内容を説明するようなものがよい)
• 準備が整い次第できるだけ早くPull Requestを作成し、コラボレーションを始める
  • コードレビューやCIを実施しながらブランチにコミットを重ねていく
• レビュー完了、CI通過、等々なんらかの基準を満たした後、当該ブランチをデプロイする
  • 問題が発生した場合にはmasterをデプロイし直す
• デプロイ後問題なければ当該ブランチをmasterにマージし、当該ブランチを削除する

特にデプロイの箇所が2011年当時とは変わっていますが（当時はmasterにマージしてからデプロイする旨記述していた）、大枠はこのようになります。

GitHub Flowがなぜ重要か、どう便利なのか

GitHub Flowは既にオープンソースの世界ではデファクト・スタンダードと言ってもいい開発フローだと思います。もちろん必ずしもすべてのプロジェクトが上記のとおりに開発しているわけではありませんが、Pull Requestをベースにした開発フローという意味では、ほぼほぼ近いやり方をほとんどのプロジェクトが採用していると行っても過言ではありません。

我々GitHubも、もちろんこのGitHub Flowに沿って開発を行っています。この開発フローは特にGitHub社のようにプロジェクトメンバーが世界中に散らばっているようなケースによくフィットします。Pull Requestをベースにした非同期なコミュニケーションをベースにしているからです。オープンソースプロジェクトももちろん同じ状況ですから、GitHub社はまさにオープンソースプロジェクトのように社内のソフトウェア開発を行っていて、その成果（つまりGitHub自身のリリース）をオープンソースコミュニティに対して提供しているわけです。

GitHub Flowを実践してみよう

まずは習うより慣れろということで、実際にGitHub Flowを実践してみましょう。既にご自身のリポジトリがある場合はそれを使って実践するのが一番いいのですが、ここでは一旦新規にリポジトリを作るところから始めてみましょう。

準備: リポジトリを作成しよう

まずはGitHub Flowの練習をするためのリポジトリを作成しましょう。

次の図を参考に、右上の"+"メニューから"New repository"を選択してください。

すると次のような画面が現れますので、"Repository name"はじめ、必要な情報を入力します。

"Repository name"にはお好きな名前を入れてください。名前に悩む場合は"github-flow-practice"としておくといいでしょう。

"Description"はオプションです。このリポジトリの説明文を入れてください。入力しなくても大丈夫です。

次にこのリポジトリをPublicにするかPrivateにするかを選びます。リポジトリをPrivateにするには利用料金が必要です。ここではPublicにしましょう。

次に"Initialize this repository with a README"にチェックを入れます。これはこのリポジトリのREADMEファイルをこのタイミングで生成する機能です。ここにチェックを入れておくと次の作業がスムーズになりますので入れておいてください。

.gitignoreとライセンスファイルを追加するオプションがありますが、ここでは特に入力しなくとも大丈夫です。

最後に"Create repository"を押せばリポジトリを作成できます。

作成が終わるとこのような画面が出てくると思います。ユーザー名やリポジトリ名の違い、ライセンスファイルを作成したかどうかで少し見た目が違うかもしれませんが。ともあれ、これでリポジトリの作成ができました。

ブランチを作ろう

ではここからGitHub Flowを体験してみましょう。ここでは先程生成したREADME.mdというファイルの内容を変更してみましょう。

いきなりこのREADME.mdファイルを変更することももちろんできますが、ここではGitHub flowに従って、まずブランチを作成してみましょう。

ブランチを作成する方法はいくつかありますが、ここではWeb UIの機能を使ってやってみましょう。左中ほどにある"Branch: master"というプルダウンリストをクリックすると、いまあるブランチの一覧が見れるようになっています。このタイミングでクリックするとmasterブランチ一つしか見えません。

このプルダウンリストを使ってブランチを作成できます。ここにあるテキストフィールドに文字を入力するとブランチをインクリメンタルサーチできるのですが、存在しないブランチ名を入力すると次のように"Create branch: xxxx"と表示されます。

この状態でEnterを押すか、青い部分をクリックすると、入力した名前で新しいブランチを作成できます。ブランチを作成すると次のように水色の背景のメッセージが表示されます。

おめでとうございます。これでブランチ作成ができました！

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

ブランチを作成できたら、いよいよファイルの変更をしましょう。

README.mdファイルをクリックしてください。次に右にある鉛筆ボタンをクリックしてください。

するとエディタが開きますので、次のように変更します。

ファイルの内容を変更したら、この変更をコミットします。コミットメッセージをたとえば次のように入力してください。コミットメッセージを入力したら"Commit changes"ボタンを押せばコミットできますが、その前に今作業をしているブランチが間違いなく先ほど作成したブランチであることを確認しましょう。

ボタンのすぐ上に2つのラジオボタンがあります。"Commit directly to the editing-readme branch"と、先程作成したブランチ名が表示されていれば問題ありません。もしここでmasterブランチが表示されていた場合には、下のラジオボタンを選択して、この場でブランチを作成してプルリクエストを作成することもできます。

"Commit changes"ボタンを押せば、コミットが完了し、次のように表示が変わります。

これで"editing-readme"ブランチに変更をコミットできました。ちなみにこの時"master"ブランチはどうなっているでしょうか？ プルダウンリストを使ってブランチを変更してみましょう。すると次のように、"master"ブランチにはまだ変更が加わっていないことがわかります。

では、この変更をmasterブランチに取り込むにはどうすればいいでしょうか。

Pull Requestを作ろう

ここまでブランチを作成して変更を加えました。まだmasterブランチには変更が入っていません。加えた変更をmasterに入れたいとき、作成するのがPull Requestです。

Pull RequestはGitHub Flowの中心となる機能です。この機能を使って、変更をmasterに対して取り込んでもらうように提案できます。またPull Request上では@メンション機能を使って関係者に通知を飛ばしたり、コードレビューをしたり、仕様について議論したりできます。

Pull Requestはいつでも作成できますので、変更作業の途中でも作成できます。できるだけ早いタイミングでPull Requestを作成して他者と議論をすることで、より内容について精査でき、コードの品質を上げることができます。

それではPull Requestを作成してみましょう。"Pull Requests"というタブをクリックし、右側にある"New pull request"ボタンを押してください。

するとPull Request作成画面になります。ブランチ選択のプルダウンリストが2つ並んでいます。baseはそのままにして、compareの方を自身が作成したブランチに変更してください。すると"Create pull request"ボタンが出てきますのでこれを押してください。

次のような画面が出てきますので、このPull Requestのタイトルを編集し、内容を記入して再度"Create pul request"ボタンを押してください。内容には、このPull Requestを作成した意図などを記入すると良いでしょう。

また@メンション機能などもここで使えます。

ボタンを押すと次のようにPull Requestが作成されます。

おめでとうございます！ はじめてのPull Requestができました！

コードレビューをしてみよう

コードレビューをしてみましょう。"Files changed"タブをクリックすると、このPull Requestに含まれるファイルの変更差分をみることができます。

この記事をご覧頂いているタイミングによっては、このタブの下に最近追加した新しい機能についての説明ページが出てくるかもしれません。ぜひお読みいただいて理解を深めてください。必要ない場合には"x"ボタンを押して消してください。

このタブではファイル変更差分の一行ごとにコメントをつけることができます。コメントを入れたいところにマウスを持っていくと、次の図のように青いプラスボタンが出てきます。

これをクリックするとコメント入力画面が出てきますので、適切なコメントを入力してください。ここでは自己紹介文を足すように促すコメントを入れています。

"Start a review"を押すと次のように画面が変わり、レビュープロセスがスタートします。まだこのタイミングではコメントした内容が相手には見えない状態です（この例ですと自分でPull Requestを作って自分でレビューコメントを書いているためにコメント内容も見えていますが）。

下部にある"Finish your review"を押すと、レビュープロセスを終わらせて相手に通知できます。押してみましょう。

するとこのようにReviewコメントをサブミットする画面が出てきます。ここで一連のレビューコメントに対してのサマリを記入することもできます。また、このレビューを"Comment"とするのか、"Approve"とするのか、"Request changes"という扱いにするかを選ぶこともできます。今回は自分自身でレビューしているために"Comment"しか選べません。

今回はレビューコメントが1つしかありませんから、サマリは必要ないと思います。そのまま何も記入せずに"Submit review"を押してみましょう。

すると次のように、レビュー内容がPull Requestの"Conversation"タブに出てきます。こんな風にしてコードレビューが可能です。なお、今回追加されたコードレビュー機能についての詳しい解説は次回以降ご紹介したいと思います。

さらに変更を加えてみよう

レビュー内容を受けて、さらに変更を加えてみましょう。"Files changed"タブをクリックして、先ほどと同じように鉛筆ボタンを押してエディタを開きましょう。

変更を加えたら、前回と同じようにコミットメッセージを入力し、作業しているブランチが間違っていないことを確認して、"Commit changes"ボタンを押しましょう。すると次のように、先ほどのレビューコメントの下に行が追加されていると思います。

Pull Requestの"Conversation"タブがどうなっているかも見てみましょう。タブに戻ってみると次のように、先ほどのレビューコメントの下にコミットが追加されていることがわかります。

Pull Requestを使っているとこんな風に様々な活動が時系列に整理されて表示されるため、何が起きているのかを把握しやすいところもポイントです。

マージしよう

さて、ここまで変更を加えてきましたが、まだmasterには一切変更が加わっていません。masterに変更を加えるには、このPull Requestをマージする必要があります。

マージをしましょう。

マージをする際には、単体テストをちゃんと通っているかであるとか、適切な人からレビューを受けているか、などの条件をつけるようにするとよりよいでしょう。今回の例では一切の条件がありませんが、このあたりの運用については、次回以降で詳しく解説します。

今回はレビューも受け、レビューで受けた変更もしたのでよしとして、マージをします。

マージをするのはかんたんです。"Merge pull request"を押すだけです。このボタンを押すと、次のようにマージコミットの確認画面が出てきます。

マージコミットのメッセージ等を変更したい場合はこのタイミングで行います。なお、このようにマージコミットを作るスタイルではなく、スカッシュマージやリベースマージをすることも可能ですが、ここでは詳しくは説明しません。スカッシュマージとはなにか、ということも含めて、次回以降詳しく解説します。

"Confirm merge"を押すと、マージが完了します。マージすると次のようにいくつかのメッセージが表示されます。

まず最初のものはこのブランチをmasterにマージしたことの履歴です。またこのPull Requestを元にRevertすることもできるようになっています。このRevert機能も大変便利です。次回以降詳しく解説します。

次に青い電球マークで表示されているメッセージがあります。利用状況によってはこのメッセージが出ない人もいますが、これはCI(Continuous Integration)の設定を促すメッセージです。JenkinsやTravisCIなどのツールと組み合わせてPull Requestに対するCIを実施できます。Pull Requestに対するCIは今や必須のベストプラクティスと言っても過言ではないですが、これについても次回以降解説する予定です。

最後に表示されているのが、このPull Requestが間違いなくマージされて閉じられたことと、"Delete branch"というボタンです。GitHub Flowでは、細かくブランチを作ってPull Requestを開き、レビューとテストが通ったらすぐにマージして、ブランチを削除するという流れを推奨しています。これの意図はブランチの生存期間をとにかく短く保つことにあります。ブランチの生存期間が長ければ長いほどマージが困難になり、コンフリクトが起きやすくなるためです。

Pull Requestがマージされてしまえば、当該ブランチはもう必要ありませんので、速やかに削除することをGitHubとしては推奨しています。そのためこのタイミングで"Delete branch"ボタンが出てくるのです。このボタンを押して、ブランチを削除しましょう。

削除すると次のように削除した履歴も残ります。間違って削除してしまった場合には"Restore branch"を押せば復旧することもできますので、心配せずにどんどん削除してしまうことをおすすめしています。

おめでとうございます！ これで変更をマージできました！ masterブランチを見てみると、次のように変更が反映されているのがわかると思います。

まとめ

さて今回はGitHub Flowについて体験してみました。今回の内容で、以下のことができるようになりました。

• いきなりmasterに変更を入れず、まずブランチを作成する
• ブランチに変更をコミットする
• Pull Requestを作成する
• コードレビューをする
• レビューを受けて変更を加える
• マージする
• 不要になったブランチを削除する

これがGitHub Flowのかなり基本的な部分になります。今回はCIとデプロイについては解説しませんでした。次回以降の連載の中で、次のような内容について解説していきたいと思います。ご期待下さい！

• Pull Requestに対してCIを行うには
• GitHub Flowにおけるデプロイのタイミング、GitHubがどう行っているか
• マージに条件をつけるにはどうすればいいか
  • 承認を得ないとマージできないようにするには
  • テストをパスすることを条件とするには
  • 特定のチームだけがマージできるように制限するには
• マージの選択肢にはどんなものがあるか