Github Flow

Github Flowとは

Github Flowは次のようなルールがある。

  1. masterブランチのものは何であれデプロイ可能である
  2. 新しい何かに取り組む際は、説明的な名前のブランチをmasterから作成する(例: new-oauth2-scopes)
  3. 作成したブランチにローカルでコミットし、サーバー上の同じ名前のブランチにも定期的に作業内容をpushする
  4. フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、 プルリクエスト を作成する
  5. 他の誰かがレビューをして機能にOKを出してくれたら、あなたはコードをmasterへマージすることができる
  6. マージをしてmasterへpushしたら、直ちにデプロイをする

1.masterブランチのものは何であれデプロイ可能である

常にデプロイ可能。

常に新しいブランチを作成できる状態になっている。

masterブランチが巻き戻される(作業内容を取り消すためにブランチが古いコミットを指すようにする)ことはほぼない。

もし問題が起きたら、コミットは取り消されるか(reverted)、問題を修正した新しいコミットが行われる。

テストされていなかったり、ビルドを壊すようなコードは絶対にmasterにPushしてはならない。

2. masterから説明的なブランチを作成する

何か作業を始めたい時は、安定したmasterブランチから説明的な名前のブランチを作成する

(例. user-content-cache-key, submodules-init-task, redis2-transition)

3. 名前をつけたブランチに定期的にpushする

リモートリポジトリのmasterブランチには安易にPushしてはならないが、masterブランチ以外のブランチであれば定期的に気軽にPushしてよい。

4. いつでもプルリクエストを作る

masterブランチにマージしてもらいたい時だけでなく、あるブランチから他の(master以外の)ブランチにもPull Requestを使うことができる。

ちょっとしたアドバイスを貰いたい時などにもPull Requestを活用できる。

もしブランチがあまりに長くオープンになっていて、 masterブランチと同期しないようになってきたと感じたら、masterを(masterに、ではなく)トピック・ブランチにマージして進み続ける。

もし特定の人のレビューやフィードバックが欲しい場合は、@ユーザ名 を追加することで人々をccすることができる

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

トピックブランチをmasterにマージする時は、会社の他の人達に+1や絵文字や":shipit:"コメントをしてもらい、許可をもらってからmasterにマージする。

6. レビューのあとは直ちにデプロイする

参考

GitHub Flow (Japanese translation) · GitHub