「GitHub実践入門」でGitHub Flowを学び直した

gihyo.jp

GitHubは普段の開発でよく使っているので基本的な操作は問題ないと思っていたが、今後恥をかきたくないと思い改めて学ぶことにした。
この本はgitコマンドの基本的な使い方から始まり、GitHubのコンソールの機能の紹介、hubコマンドやいくつかのCIツールの解説(Circle CIやGitHub Actionsは載っていないが)、そして代表的な開発フローなど幅広い内容をカバーしており、これを読めばチームメンバーに迷惑をかけることはなくなるだろう。特に今回読んでみて学びが多かったのは、GitHub Flowの捉え方についてだった。

GitHub Flowに必要なこと

GitHub Flowはmasterブランチを中心に据えた開発フローであり、masterからブランチが切られ、変更がmasterに直接マージされる。この方法の特長は開発サイクルが速くなることくらいに思っていたのだが、GitHub Flowをうまく回すにはそれ以外にも条件があった。

デプロイの自動化

masterから直接ブランチを切るということは、masterが頻繁に変更されることを意味する。そしてmasterは常にデプロイ可能な状態であることが求められる。つまり、masterブランチは高速にデプロイされなければならず、それを実現できる仕組みが不可欠になる。
GitHub Flowでは、そもそも「リリース」という概念はない。1日数回のペースでデプロイが行われている企業も多い。

テストの自動化

デプロイが頻繁に行われるということは、その前のテストも頻繁に行われなければいけない。人間の手でカバーしていたら1日数回のデプロイなどできないので、テストも自動化されなければいけない。
これら2つが合わさることで、CI/CDツールが意味を持ってくる。

PRを小さくする

デプロイとテストを自動化しても、PRのレビューには人の目を入れなければいけない。もちろん文法や記法等についてはlintを入れるなどして自動化すべきだが、ロジックのレビューは必ず必要になる。ここで時間を取らないためには、PRの規模を小さくし、レビュアーが変更範囲を把握しやすくなるようにしなければならない。
レビューに時間を取られると、masterがどんどん変更されていき、それをローカルブランチに取り込んでconflict対応して...となり、ますます対応時間が増える悪循環に陥る。実際に巨大なPRを作ってしまい1か月以上経ってもマージされなかったことがあるので、この話は身につまされた。

事前に変更内容の合意を取る

開発からマージまでの時間を最小限にするには、そもそも実装が全部終わる前に確認を取ってしまえばよい。実装を始めたばかりの段階で、これからどのように変更するかの方針をPRにしておけば、もしその方針が違っていた場合にムダな実装をせずに済む。

全員の能力を底上げする

ここまではシステム上の工夫だったが、最終的にはそれぞれの開発者の能力が求められる。スキルの低い開発者がGitHub Flowを使っても、大量のレビューを食らって大きな工数がかかってしまい、高速デプロイが全然できない。身も蓋もない話だが、言われてみれば正論である。

GitHubのtipsとして今まで教わってきたことが、この本を読んで全てつながった感じがする。GitHub Flowは開発の生産性向上を目指したツールなので、ただの仕事のやり方として惰性でやるのではなく、その意味や狙いを理解したうえで使っていきたい。