こんにちは、KTです。

今年のMA11に無事参加することが出来ました。

今回は、その際に行ったGithubによるGithub-FlowおよびWIPといった開発手法について紹介します。

Github-Flow

Github-Flowなんて仰々しい名前がついていますが、開発を進める上でのブランチ運用を纏めただけのものです。

Github-Flowって？

具体的には

1. 開発者はmasterブランチから自分の開発用のトピックブランチ（名前はなんでも良い）を切って、そのブランチ上で作業し、作業が完了したらトピックブランチをPushする
2. トピックブランチの内容が問題無ければmasterブランチにマージする

という流れで開発を行うことをGithub-Flowと呼びます。

また、Github-Flowを行う上での大前提として『masterブランチの内容は必ず常にデプロイ可能でなければならない』というルールがあります。（デプロイ出来ない修正はmasterにマージしちゃダメ。絶対。）

Github-Flowについては説明は以上ですが、この流れで開発を行うために有用なツールがGithubです。

続いて、Github上でどのようにGithub-Flowで行うかを説明します。

Github-Flow on Github

Githubにはプルリクエスト（Pull Request、以下PR）と呼ばれる機能があります。

ひとことで言うと「こういう機能を作ってブランチPushしといたからmasterにPullしてね」って依頼を投げる機能です（PullしてねってRequestする）

GithubのPRで便利なところは、そのPR内で変更箇所を見ることができ、更に変更箇所に対してコメントできるところです。これにより、チームメンバーの誰であってもPR内でコードレビューが可能になります。

さて、具体的に開発の流れを見ていきましょう。

1. 開発者がmasterブランチから作業用のトピックブランチを作成
2. トピックブランチ上で作業
3. 作業が完了したらトピックブランチをpush
4. Github上から、トピックブランチのPRを作成
5. チームメンバー全員でPR上でコードレビュー（問題があれば2.に戻る）
6. 問題が無ければ、Github上でトピックブランチをmasterブランチにマージ（ボタン一つで可能）
7. そのトピックブランチ上の作業が全て終わっているのであればGithub上でトピックブランチを削除（ボタン一つで可能）

1〜3.は開発者それぞれのPC上で実施し、4以降は全てGithub上で行えます。

ここで気をつけなければいけないのは、6,7.についてはGithub上で誰でもボタン一つで行えてしまうため、レビューが完了していなくてもマージしてしまうことが可能です。このため、予めマージボタンを押す人（リーダー？）を決めておいたほうがよいでしょう。

WIP

さて、ここまでGithub-Flowについて説明してきましたが、タイトルにはもう一つ用語が書いてありますね。そう、「WIP」です。

ここからはWIPについて紹介していきましょう。

WIPって？

WIPはWork In Progressの略です。日本語でいうと作業中とかそういった意味になります。

先程まで紹介したGithub-Flowですが、一つ欠点（とは呼べないほど小さなことですが）があります。それは、PRを投げる（＝作業が完了してpushする）までレビューを受けられないことです。

「当たり前じゃん？」って感じですかね？でも考えてみてください。小さなトピックならそれでも良いかもしれないですが、複数ファイルに跨がるような大規模な作業のトピックの場合、部分部分の作業が完了する度にレビューを受けられた方が便利だと思いませんか？

トピックが複数のやること（ToDO）を持つような場合に、小分けにしてToDO毎にPushしてレビューを受けられるような運用方法をWIPと言ったりします。

どうやるの？

WIPは運用方法であり、Githubにそれを実現する機能はありません。そのため、WIPを実現するには、

1. トピックブランチを切る
2. トピックブランチに対する空コミットを作る（PRを投げるために）
3. PRを投げる（この際、PRのタイトルに「WIP」という文字列を含める）
4. PR内にToDOを並べる
5. ToDOを消化する度にトピックブランチにPushする
6. 全てのToDOが完了するまで4.を繰り返す
7. 全てのToDOが完了したら、PRのタイトルから「WIP」の文字列を削除する
8. レビューがOKならmasterにマージする

というように、WIPを他の人に示すようなルールを敷くことで実現します。

4〜5.でToDO毎にどのようなコミットをしたかが変更履歴として見えるため、作業者はToDOを消化しつつ、他の人は既にPushされている変更履歴をレビューする。といった並行作業が可能になります。

4.でPR内にToDOを並べると書きましたが、GithubのPRの本文はmarkdownで書けるため、

- [ ] ToDO1
- [ ] ToDO2
- [ ] ToDO3

のように記載すると、チェックボックスでToDOを並べることが出来ます。おわったToDOにチェックを付けるようにすれば、他の人にも進捗が分かりやすくていいですね。

※ なお、2.で空コミットを作ってPushするとありますが、初回のToDOコミット時にPRを作っても問題ありません（というかそちらの運用の方が多いと思います）。あくまで１つのPR内で複数のToDOがある場合に小分けにPushして都度レビューしてもらうことが目的となります。

以上、でわでわ。