Flowの基礎」と題して、GitHubを使う上での基本的な部分について解説したいと思います。言っても、Git自体の利用方法については既に書籍もたくさんありますし、Web上にも記事が多数ありますので、ここでは特に触れないことにします。これからGit自体を学習する場合に有用なリンク集は、下記のブログ記事にまとめてありますので参考にしてください。Flowについて解説します。Flowというのは、GitHub社が提唱している効果的なワークフローのことです。この言葉は2011年に発表されたこの記事が起源だと思います。Flowというワークフローに対して、もう少し簡単で理解しやすいワークフローとして提案したのが最初です。最初のブログ発表から数年たち、内容もだいぶ洗練されてきました。現在では簡単なガイドをWeb上に公開しています。英語ではありますが、これを読むと大枠が理解できるかと思います。FlowをGitHubでは現在ではどのように実践しているかも解説しました。こちらもぜひご覧ください。Flow実践にあたっての要点は下記にまとめることができます。Requestを作成し、コラボレーションを始めるコードレビューやCIを実施しながらブランチにコミットを重ねていくレビュー完了、CI通過、等々なんらかの基準を満たした後、当該ブランチをデプロイする問題が発生した場合にはmasterをデプロイし直すデプロイ後問題なければ当該ブランチをmasterにマージし、当該ブランチを削除する特にデプロイの箇所が2011年当時とは変わっていますが(当時はmasterにマージしてからデプロイする旨記述していた)、大枠はこのようになります。Flowは既にオープンソースの世界ではデファクト・スタンダードと言ってもいい開発フローだと思います。Requestをベースにした開発フローという意味では、ほぼほぼ近いやり方をほとんどのプロジェクトが採用していると行っても過言ではありません。Flowに沿って開発を行っています。この開発フローは特にGitHub社のようにプロジェクトメンバーが世界中に散らばっているようなケースによくフィットします。Requestをベースにした非同期なコミュニケーションをベースにしているからです。オープンソースプロジェクトももちろん同じ状況ですから、GitHub社はまさにオープンソースプロジェクトのように社内のソフトウェア開発を行っていて、その成果(つまりGitHub自身のリリース)をオープンソースコミュニティに対して提供しているわけです。Flowを実践してみましょう。ご自身のリポジトリがある場合はそれを使って実践するのが一番いいのですが、ここでは一旦新規にリポジトリを作るところから始めてみましょう。Flowの練習をするためのリポジトリを作成しましょう。repository"を選択してください。name"はじめ、必要な情報を入力します。name"にはお好きな名前を入れてください。名前に悩む場合は"github-flow-practice"としておくといいでしょう。"Description"はオプションです。このリポジトリの説明文を入れてください。入力しなくても大丈夫です。次にこのリポジトリをPublicにするかPrivateにするかを選びます。リポジトリをPrivateにするには利用料金が必要です。ここではPublicにしましょう。README"にチェックを入れます。これはこのリポジトリのREADMEファイルをこのタイミングで生成する機能です。ここにチェックを入れておくと次の作業がスムーズになりますので入れておいてください。.gitignoreとライセンスファイルを追加するオプションがありますが、ここでは特に入力しなくとも大丈夫です。repository"を押せばリポジトリを作成できます。作成が終わるとこのような画面が出てくると思います。ユーザー名やリポジトリ名の違い、ライセンスファイルを作成したかどうかで少し見た目が違うかもしれませんが。これでリポジトリの作成ができました。Flowを体験してみましょう。ここでは先程生成したREADME.mdというファイルの内容を変更してみましょう。flowに従って、まずブランチを作成してみましょう。UIの機能を使ってやってみましょう。master"というプルダウンリストをクリックすると、いまあるブランチの一覧が見れるようになっています。このタイミングでクリックするとmasterブランチ一つしか見えません。このプルダウンリストを使ってブランチを作成できます。xxxx"と表示されます。この状態でEnterを押すか、青い部分をクリックすると、入力した名前で新しいブランチを作成できます。ブランチを作成すると次のように水色の背景のメッセージが表示されます。おめでとうございます。これでブランチ作成ができました!ファイルを変更してコミットしようブランチを作成できたら、いよいよファイルの変更をしましょう。README.mdファイルをクリックしてください。次に右にある鉛筆ボタンをクリックしてください。するとエディタが開きますので、次のように変更します。ファイルの内容を変更したら、この変更をコミットします。コミットメッセージをたとえば次のように入力してください。changes"ボタンを押せばコミットできますが、その前に今作業をしているブランチが間違いなく先ほど作成したブランチであることを確認しましょう。ボタンのすぐ上に2つのラジオボタンがあります。branch"と、先程作成したブランチ名が表示されていれば問題ありません。ここでmasterブランチが表示されていた場合には、下のラジオボタンを選択して、この場でブランチを作成してプルリクエストを作成することもできます。changes"ボタンを押せば、コミットが完了し、次のように表示が変わります。これで"editing-readme"ブランチに変更をコミットできました。プルダウンリストを使ってブランチを変更してみましょう。すると次のように、"master"ブランチにはまだ変更が加わっていないことがわかります。この変更をmasterブランチに取り込むにはどうすればいいでしょうか。Requestを作ろうここまでブランチを作成して変更を加えました。masterブランチには変更が入っていません。Flowの中心となる機能です。この機能を使って、変更をmasterに対して取り込んでもらうように提案できます。Request上では@メンション機能を使って関係者に通知を飛ばしたり、コードレビューをしたり、仕様について議論したりできます。Requestはいつでも作成できますので、変更作業の途中でも作成できます。Requestを作成して他者と議論をすることで、より内容について精査でき、コードの品質を上げることができます。Requestを作成してみましょう。request"ボタンを押してください。Request作成画面になります。ブランチ選択のプルダウンリストが2つ並んでいます。baseはそのままにして、compareの方を自身が作成したブランチに変更してください。request"ボタンが出てきますのでこれを押してください。request"ボタンを押してください。Requestを作成した意図などを記入すると良いでしょう。@メンション機能などもここで使えます。Requestが作成されます。Requestができました!コードレビューをしてみようコードレビューをしてみましょう。Requestに含まれるファイルの変更差分をみることができます。この記事をご覧頂いているタイミングによっては、このタブの下に最近追加した新しい機能についての説明ページが出てくるかもしれません。お読みいただいて理解を深めてください。必要ない場合には"x"ボタンを押して消してください。このタブではファイル変更差分の一行ごとにコメントをつけることができます。コメントを入れたいところにマウスを持っていくと、次の図のように青いプラスボタンが出てきます。これをクリックするとコメント入力画面が出てきますので、適切なコメントを入力してください。ここでは自己紹介文を足すように促すコメントを入れています。review"を押すと次のように画面が変わり、レビュープロセスがスタートします。Requestを作って自分でレビューコメントを書いているためにコメント内容も見えていますが)。review"を押すと、レビュープロセスを終わらせて相手に通知できます。するとこのようにReviewコメントをサブミットする画面が出てきます。ここで一連のレビューコメントに対してのサマリを記入することもできます。changes"という扱いにするかを選ぶこともできます。今回は自分自身でレビューしているために"Comment"しか選べません。今回はレビューコメントが1つしかありませんから、サマリは必要ないと思います。review"を押してみましょう。Requestの"Conversation"タブに出てきます。こんな風にしてコードレビューが可能です。今回追加されたコードレビュー機能についての詳しい解説は次回以降ご紹介したいと思います。変更を加えてみようレビュー内容を受けて、さらに変更を加えてみましょう。changed"タブをクリックして、先ほどと同じように鉛筆ボタンを押してエディタを開きましょう。changes"ボタンを押しましょう。すると次のように、先ほどのレビューコメントの下に行が追加されていると思います。Requestの"Conversation"タブがどうなっているかも見てみましょう。タブに戻ってみると次のように、先ほどのレビューコメントの下にコミットが追加されていることがわかります。Requestを使っているとこんな風に様々な活動が時系列に整理されて表示されるため、何が起きているのかを把握しやすいところもポイントです。マージしようさて、ここまで変更を加えてきましたが、まだmasterには一切変更が加わっていません。Requestをマージする必要があります。マージをする際には、単体テストをちゃんと通っているかであるとか、適切な人からレビューを受けているか、などの条件をつけるようにするとよりよいでしょう。今回の例では一切の条件がありませんが、このあたりの運用については、次回以降で詳しく解説します。今回はレビューも受け、レビューで受けた変更もしたのでよしとして、マージをします。マージをするのはかんたんです。request"を押すだけです。このボタンを押すと、次のようにマージコミットの確認画面が出てきます。マージコミットのメッセージ等を変更したい場合はこのタイミングで行います。このようにマージコミットを作るスタイルではなく、スカッシュマージやリベースマージをすることも可能ですが、ここでは詳しくは説明しません。スカッシュマージとはなにか、ということも含めて、次回以降詳しく解説します。merge"を押すと、マージが完了します。マージすると次のようにいくつかのメッセージが表示されます。最初のものはこのブランチをmasterにマージしたことの履歴です。Requestを元にRevertすることもできるようになっています。このRevert機能も大変便利です。次回以降詳しく解説します。次に青い電球マークで表示されているメッセージがあります。Integration)の設定を促すメッセージです。Requestに対するCIを実施できます。Requestに対するCIは今や必須のベストプラクティスと言っても過言ではないですが、これについても次回以降解説する予定です。branch"というボタンです。Requestを開き、レビューとテストが通ったらすぐにマージして、ブランチを削除するという流れを推奨しています。これの意図はブランチの生存期間をとにかく短く保つことにあります。ブランチの生存期間が長ければ長いほどマージが困難になり、コンフリクトが起きやすくなるためです。Requestがマージされてしまえば、当該ブランチはもう必要ありませんので、速やかに削除することをGitHubとしては推奨しています。branch"ボタンが出てくるのです。このボタンを押して、ブランチを削除しましょう。削除すると次のように削除した履歴も残ります。branch"を押せば復旧することもできますので、心配せずにどんどん削除してしまうことをおすすめしています。masterブランチを見てみると、次のように変更が反映されているのがわかると思います。Flowについて体験してみました。今回の内容で、以下のことができるようになりました。Flowのかなり基本的な部分になります。今回はCIとデプロイについては解説しませんでした。次回以降の連載の中で、次のような内容について解説していきたいと思います。ITコンサルタントとしてキャリアをスタート。その後コンサルタントからプログラマーに転身し、パッケージソフトウェア開発、Webサービス開発を経て、2015年現在GitHubにてソリューションエンジニアとして働いている。Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。ITがお届けするポッドキャストです。