【入門】Github Flowとは？使い方の基本

Github FlowはGitHubを使いチームで共同開発を行う際に、役に立つワークフローです。GitHubによりソースコードの共有は実現しますが、GitHub Flowを使うことで共同開発をスムーズに進めることが可能です。

この記事ではGitHub Flowとは何かや、よく比較されるgit-flowとの違い、GitHub Flowの使い方について解説します。この記事を読めば、すぐにでもチームでの共同開発にGitHub Flowを採用できるでしょう。

※本記事は、GitHubの基本について理解している読者の方向けです。GitHubの基本については以下記事で解説しておりますので、よろしければあわせて参考にして下さい。

GitHub Flowとは【GitHub社も使うシンプルなワークフロー】

「GitHub Flow」とは、GitHubで開発を進める際に使えるシンプルなワークフローです。GitHub社もGitHub開発の際に、このワークフローを使っています。

GitHub Flowの特徴は、メインとなるmasterブランチと作業用のブランチ（featureブランチ）の2種類だけでワークフローをすすめることです。そのため明瞭で使いやすく、小規模～大規模の開発まで迅速に開発をすすめたいときに適しています。GitHub Flowは簡単なので、GitHub初心者やプログラマー以外のユーザーでも扱いやすいでしょう。

GitHub Flowのように、あらかじめブランチの運用ルールを決めて開発をすすめることや、その際の運用ルールのことを「ブランチ戦略」と呼びます。

「git-flow」との違い

「git-flow」は、GitHub Flowとよく比較されるブランチ戦略（ワークフロー）です。masterブランチと作業用のブランチしか使わないGitHub Flowに対し、git-flowでは以下5種類のブランチを使い分けます。

【メインブランチ】
文字通りメインで使うブランチ。これらブランチは削除されない。

ブランチ名	概要
masterブランチ	リリース済のソースコードを管理するブランチ
developブランチ	次のリリースに備え、最新のソースコードを管理するブランチ

【サポートブランチ】
masterブランチやdevelopブランチから作成し、実際に作業を行うブランチ。作業完了後は削除される。

ブランチ名	概要
featureブランチ	新しい機能の開発や簡単なバグ修正などの開発作業を行うためのブランチ。 developブランチからの分岐として作成され、developブランチにマージする。
releaseブランチ	リリース作業を行うためのブランチ。 developブランチからの分岐として作成され、developブランチとmasterブランチにマージする。
hot-fixブランチ	緊急の修正作業を行うためのブランチ。 masterブランチからの分岐として作成され、developブランチとmasterブランチにマージする。

2種類のみのブランチで運用するGitHub Flowに比べ、それぞれ役割をもつ5種類のブランチを使い分けるgit-flowは複雑で大規模な開発に適しています。

反対に、それほど規模が大きくない開発では、git-flowは複雑で使いにくいと感じることもあるでしょう。またWebアプリケーションのデプロイを1日複数回行うといった、フットワーク軽く開発を続ける現場では、シンプルなGitHub Flowの方が適しています。

GitHub Flowを使うときに守るべき6つのルール

GitHub Flowを使うときは、6つのルールを守ることになっています。一番重要なのが最初のルールで、その他のルールは最初のルールを実現するのが目的です。以下、各ルールの概要をみていきましょう。

①「masterブランチのものは何であれデプロイ可能である」

GitHub Flowではmasterブランチへマージする場合、すぐにデプロイすることを求めています。このルールを前提にテストやレビューを行い、慎重にマージすることが必要です。

②「masterから説明的なブランチを作成する」

機能追加やバグ修正など、何がしかの作業を行う際は必ずmasterブランチから説明的なブランチ（作業用ブランチ）を作成します。そうして作業用ブランチで開発作業を行い、最終的にmasterブランチへマージされるようにするのです。

作業用ブランチの名称に決まりはありません。何の作業をしているか、わかりやすい名前をつけましょう。

③「名前をつけたブランチに定期的にpushする」

ローカルリポジトリから定期的にリモートリポジトリへpushし、開発の内容をスムーズに他メンバーと共有します。メンバー間の情報共有を徹底し、変更箇所が衝突するなどのトラブルを防ぐのが目的です。

④「いつでもプルリクエストを作る」

フィードバックやアドバイスが欲しいときや、masterブランチへマージするときなどは必ずプルリクエストを作成しレビューを求めます。プルリクエストを使うことで、シンプルかつ確実にレビューが行えるようになるためです。

⑤「マージはプルリクエストがレビューされた後だけ」

masterブランチへマージする際は、必ずプルリクエストを行うことを求めます。masterブランチを、常にデプロイ可能な状態に保持するためです。

⑥「レビューのあとは直ちにデプロイする」

レビューしたら、すぐにデプロイします。デプロイせずに放置してしまうと、他の開発者とのマージが衝突する可能性が生じるからです。GitHub Flowでは、このようなトラブルの可能性を排除し、シンプルで信頼性の高いワークフローを回せるようにします。

GitHub Flowの流れ・使い方

GitHub Flowの概要やルールが理解できれば、簡単にこのフローを使えます。ここではソフトウェアなどの開発をするケースを例に、GitHub Flowの流れ・使い方をみていきましょう。

【1】作業用ブランチを作成し開発作業を行う

まずは作業用ブランチを作成し、開発作業を開始します。作業用ブランチの名称は任意です。分かりやすいブランチ名をつけましょう。作業用ブランチでの開発作業中は、定期的にリモートリポジトリへプッシュし、他の開発者と開発状況を共有できるようにします。

【2】プルリクエストを実行する

作業用ブランチで開発作業をすすめmasterブランチへマージできるようになったら、プルリクエストを実行し他開発者にレビューを依頼しましょう。なおGitHub Flowを使う場合は開発作業が途中の状態でも、他開発者へアドバイスを求めるためにプルリクエストを実行します。プルリクエストは、アドバイスをもらうためだけの利用も可能です。

【3】コードレビューを行う

プルリクエストを受け取ったらコードレビューを行い、問題がなければmasterブランチへマージします。なおGitHub Flowでは、開発途中の段階でアドバイスをもらうために、プルリクエストが行われることもあるので注意して下さい。その場合は、コードレビュー後、プルリクエストを実行した開発者にアドバイスをしましょう。

【4】デプロイする

masterブランチへマージを実行後、すぐにデプロイを行います。デプロイが遅れて他の開発者のマージと衝突するなどのトラブルを避けるためです。速やかにマージを行うことで、GitHub Flowによる開発の信頼性が高まります。

まとめ

GitHub Flowは、GitHubによる共同開発をスムーズに進めるためのシンプルなワークフローです。masterブランチと作業用ブランチのみを利用するGitHub FLowは、明瞭でわかりやすく小規模～大規模な開発まで活用できます。

よく比較されるgit-flowは、5種類のブランチを適宜使い分ける複雑なワークフローです。git-flowは大規模な開発に適しており、よりシンプルで使いやすいGitHub Flowとは特徴が大きく異なります。

GitHub Flowを採用する場合、masterブランチは常にデプロイ可能な状態にしておくことが必要です。そのため、マージはコードレビューが完了したあとにだけ実行し、レビュー後はすぐにデプロイを行うようにします。定期的にリモートリポジトリへプッシュし情報共有したり、プルリクエストによって積極的にコードレビューを行なったりすることも重要です。