GitHub Flowについて -introductionでは基本的なルールを挙げました。 次はそのルールに基づいて実際にどのように運用していくかを見ていきます。

masterブランチは常にデプロイ可能である

masterブランチは常にデプロイ可能である、もしくは数時間後にはデプロイ出来るように準備されている、という状態でなければなりません。 masterブランチがロールバックすることはなく常に安定でバグや不具合が残っている状態ではいけません。このためにmasterブランチへのpushは慎重に行わなければなりませんが、自分の加えた変更を反映させたいときはプルリクエスト(PR)を作成することで対処します。

新機能追加やバグ修正などはmasterブランチから作成する

開発者は常にmasterブランチから自分の作業用ブランチを作成します。ここでとても重要なのは作成したブランチにわかりやすい名前をつけることです。この利点は他人から見てどのような作業を行っているかがわかりやすいこと、しばらく時間が経ってしまった後でも自分が何をしていたのかが分かりやすくなることです。この名前の付け方をチームで統一する（ブランチ命名規則の作成）ことでチームでの開発やブランチの引き継ぎ、レビューはより捗るようになるでしょう。

作成したブランチはローカルでコミットしサーバー上の同じ名前のブランチに定期的に作業内容をpushする。

サーバー上のブランチに定期的にpushすることはどのような開発環境(例えば自宅やカフェなど職場以外の場所)でも作業が行えるだけでなく、チームの他の人からも作業経過が見れるようになるので便利です。masterには一切変更を加えないので迷惑になることもなく定期的にpushすることで差し戻しや変更のリセットも容易になります。

長くなってしまうので次回はプルリクエストの作成から見ていきたいと思います。