このすみノート

Webエンジニアが技術や趣味を書くブログです。

git-flowとgithub-flowについて整理しつつ、違いについて解説する

チーム開発実践入門を読み返しているのですが、その中に「git-flow」と「github-flow」がありました。

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

既に多くのエンジニアが、Gitを使って開発しているかと思いますが、私も主に「git-flow」をベースに開発しています。

ただ、改めて読み返してみると「github-flow」は衝撃的なので、整理しつつ解説していきたいと思います。

git-flow

私の予想では、git-flowは多くの企業で使われているのではないかと予想しています。ブランチの登場人物こそ多いのですが、一度理解してしまえば難しくはありません。

メインブランチ

メインブランチは、常に存在するブランチです。

(メインブランチ)master

本番環境のブランチです。masterブランチにマージされたコードは、本番環境へとリリースされます。

重要な事は、常に本番環境と同一の状態を維持する必要があるということです。これによって、いつでも本番環境を再現できる環境が整います。

(メインブランチ)develop

開発用のブランチです。開発が完成した機能および修正から、developブランチへとマージされていきます。

ある程度の修正が溜まった段階(例えば、スクラムであればスプリントの終わり)で、リリース準備を経てmasterブランチへとリリース(マージ)されていきます。

サポートブランチ

開発中や対応中の間だけ存在し、役目を終えたら消えていくブランチです。

(サポートブランチ)feature

developから派生し、機能の追加や、優先度の低いバグ修正などの度に発生するブランチです。GitHubをご利用であれば、特定のissueを対応するために、issue毎にブランチとして切られたりします。

機能の開発が完了し、developブランチにマージされたら、役目を終えて消えていきます。

ただし、developブランチにマージをする際に、きちんとマージリクエスト(プルリクエスト)を発行していれば、記録としては残ります。ブランチは消えても、何を変えたのかはプルリクエストを見れば分かるのです。

(サポートブランチ)release

developから派生をし、リリース準備をするためのブランチです。releaseブランチは、masterへのリリースが終われば消えることもあれば、検証環境に対応したブランチとして、常に残しておく場合もあります。

(サポートブランチ)hotfix

緊急的なバグ修正などのために、masterから派生するブランチです。直接masterから派生し、直接masterへとマージされます。

通常であれば「feature => develop => release => master」の流れでリリースされるのですが、緊急的なトラブル対応では時間的な余裕がありません。

緊急時のトラブル対応として切られるのが、hotfixブランチなのです。

f:id:konosumi:20180429221140j:plain

github-flow

以上が「git-flow」の解説なのですが、それに対して「github-flow」は、あまりにシンプルすぎて読んでいて笑っちゃいました。

  • masterのものはすべてリリース可能である
  • 新しく何かをするときはmasterから直接ブランチを作る
  • 作成したブランチはローカルマシンにコミットして、リモートリポジトリにも同じ名前のブランチとして定期的にPushする
  • 開発が完了したらmasterへPull Requestを送る
  • Pull Requestがレビューされたらmasterにマージし、その場で本番環境にリリースする

引用:チーム開発実践入門

これだけなんですってよ奥さん!

要は、常にリリース可能なコードを生み出していて、その場で本番環境へとリリースするのがgithub-flowなのです。

過去に書いた「esa.ioの育て方」の記事で「30分後には修正版をリリースすることを目指す」という話がありましたが、正にこれを実践しているのがGitHubという企業です。

esa.ioの育て方の講演を観れなかったので、スライドから内容を紐解いてみる - このすみろぐ

さいごに

「github-flow」の究極のスピード感を実現するためには、CI(継続的インテグレーション)やCD(継続的デリバリー)の環境整備に加えて、しっかりしたプルリクエストのレビュー体制の構築が必要不可欠です。

まさか、普段何気なく使っているGitHubの裏で、一日に何十回もリリースが行われているとは思いませんでした。GitHub恐るべし。

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)