「Working In Progress」な WIP Pull Request ～Github-flowの新たな使い道

「Working In Progress」な WIP Pull Request という概念を知ったのでメモ。

【元ネタ】
Github を使って雑誌原稿を書く - naoyaのはてなダイアリー

git commit --allow-empty を使った WIP PR ワークフロー - Qiita

WIP (Work in Progress) な Pull Request を目立たなくする Chrome 拡張をリリース - @kyanny's blog

非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog

github を用いた開発フロー テンプレート

pull request を利用した開発ワークフロー // Speaker Deck

「Working In Progress」な WIP Pull Request とは、ソースのパッチを書き上げた所でPull Reuqest するのではなくて、いきなり Pull Request を出してしまって、そのあとはその Pull Request に、コーディングの進捗に合わせてコミットしていくやり方らしい。

WIP PR とも略されるらしい。

この手法の良い点は、PullRequestする対象のパッチが完成していなくても、まずは送れば、そのやり取りがチケットのコメントのように記録されることだ。

(引用開始)
作業途中のトピックブランチを PR することによって

・早期にコードレビューのプロセスをまわせるので仕様誤認や設計不備があった場合の修正コストが比較的低い
・修正コストが低いため、レビュワーも気兼ねなく指摘することができる
・実装完了後のコードレビューだと「ここはもう少しこうしたほうがいいけど、スケジュールも詰まってるしすぐに問題になることはなさそうだから今回はこれでいいや…」となりがちです
・作業に着手した段階で PR が作成されるので進捗を追いやすい / 他のメンバーが何をやっているか可視化される

といったメリットがあります。
(引用終了)

WIP PRという言い方も絶妙。
つまり、仕掛中(作業中で未完成)のパッチを送って、お互いにそのパッチについて、議論しながらパッチを改善していくわけだ。
まさに「仕掛中(WIP)」なわけだ。

普通のパッチ送付ならば、不完全なパッチは送られても正直困る。
レビューもできないし、無駄な時間がかかるだけ。

しかし、WIP Pull Requestは、Pull Requestの行為そのものがチケットの機能と一体化しており、Pull Requestのやり取りが時系列に記録される。
そのおかげで、当人同士も情報共有できるし、パッチのやり取りが全員に公開されるので、進捗も分かりやすい。

WIP Pull Requestの機能を振り返ると、チケットよりもかなりラフというか、アバウトな感じだ。
もっと気楽にやり取りして、masterにある成果物を成長させる。

チケット(Issue)という概念は、もっと厳格なものだ。
ステータスによって完了条件がはっきりしているし、ステータスの遷移によるワークフローも厳格に定義できる。
でも、その厳格さが面倒という声もよく聞く。
WIP Pull Requestなら、チケット管理すべきほどでない場合に使える。

WIP Pull Requestの場合、仕掛中のプルリクエストがOKだけでなく、そのチームでWIP制限(仕掛り制限)を設ければ、無駄な作業を減らすような運用も可能かもしれない。

GitHubを見ていると、単なるコーディングだけでなく、原稿を書くという行為に携わる人は全員慣れた方が良いのだろうと思ってくる。
生産性が全く違ってくるわけだ。
そして、GitHubが普通の人にも普及するようになれば、法律や文学などのお固い分野も大きく変わるだろうと直感する。

GitHubによるソーシャルコーディングが法律や出版物を変革させる可能性: プログラマの思索