Github Flowの概要

Github FlowはGitのブランチ管理をルール化したシンプルなワークフローで、短いスパンでデプロイをするようなサイトに最適です。既発のGit Flowと違ってインストールの必要がなく、ルールも簡単なため導入コストが低く抑えられます。

Github Flowは必須ブランチがmaster以外になく、そのほとんどがmasterから作業ブランチを作成、masterに作業ブランチをマージといったシンプルな流れになります。
確認用ブランチが存在しないためシンプルなブランチ管理になっており、デプロイや修正が素早く手軽に行うことができます。

作業用ブランチを作成する際は、短いスパンでデプロイすることを目指し、最小限の作業範囲で作成します。
作業範囲を狭めることにより、大きなバグの発生を抑えられるというメリットもあります。

Github Flowのルールは以下の通りです。

• masterブランチは、常時デプロイ可能な状態を保つ
• 全てのブランチはmasterブランチから作成する
• 作業内容が分かるようなブランチ名をつける
• 作業中のブランチは定期的にプッシュする
• Githubのプルリクエストを利用してレビューを行なってから、masterブランチにマージする
• マージされたmasterブランチのコードはすぐにデプロイする
• デプロイ後は速やかに作業していたブランチを削除する

シンプルなフローですが、Githubでも採用されているように、数十人規模のチームでも機能している実績があります。

Github Flowのルール

masterブランチは、常時デプロイ可能な状態を保つ
全てのブランチはmasterブランチから作成する

masterブランチは常にデプロイ可能な状態が保障されているので、安心してそこから新しいブランチを作成することができます。

作業内容が分かるようなブランチ名をつける

GitHubでは、user-content-cache-key、submodules-init-task、redis2-transitionといったブランチ名を使っているそうです。
どのような目的で作成されたブランチなのかブランチ名から推測できるので、複数のブランチを管理する際に便利です。
ブランチの種類を改修・機能追加とバグフィックスの2つに分けて、下記のような命名法を決めても良いでしょう。

• 機能追加：feature-機能を表す名称
  　例） feature-user-notice
• バグフィックス：fix-修正を表す名称
  　例） fix-login-validation

また、このルールの利点として、fetchすると他の開発者が作業しているトピックを知ることができる、という点も挙げられます。

作業中のブランチは定期的にプッシュする

作業中のブランチを定期的にpushすると、その時点の最新の作業がリモートにバックアップされます。この利点以外にも、他開発者が git getch すれば自分以外の課題がどのように進んでいるのかを確認できます。

Githubのプルリクエストを利用してレビューを行なってから、masterブランチにマージする

Githubにはプルリクエストというコードレビューの仕組みがあります。
他の開発者にプルリクエストを送り、確認や助言をしてもらいます。これで問題なければ、masterブランチにマージします。

マージされたmasterブランチのコードはすぐにデプロイする

masterブランチにマージした後は、即時でデプロイします。

デプロイ後は速やかに作業していたブランチを削除する

作業が終ったブランチがいつまでも残らないように、ローカル、リモートでデプロイしたブランチを削除します。