GitHub Flow についてのまとめ
手順
- masterブランチは常にデプロイできるようにしておく
- 新しい作業をするときはmasterブランチから何をしているかわかりやすいブランチを作成する
- 作業をしたら作成したローカルリポジトリのブランチにコミットする
- 同名のブランチをGitHubのリモートリポジトリに作成し、定期的にpushする
- masterの差分が大きくなっている場合は、リモートのmasterをローカルのmaster にpullし、ローカルのmasterを作業ブランチにマージする
- フィードバックがほしい時は、Pull Requestを作成しやりとりする
- 作業を終わったら、GitHub上でmasterに対してPull Requestを出す。
- Pull Requestがmasterブランチにマージされたら、ただちにデプロイする
特徴
masterブランチを常にデプロイできるようにすること 小さい単位でデプロイする。こうすると大きなバグが複数入ることはない。小さいな単位のバグがはいるときは、そのコミットをrevertするか、修正したコミットを出して対応する。テストや継続的インテグレーションなどのアプローチが必須。
新しい作業をするときはmasterブランチから何をしているかわかりやすいブランチを作成する 作業ブランチの名前をわかりやすいものにすることで、チームのメンバーがどのようなタスクを実施してるのかわかる。
作業ブランチでのコミットの粒度を小さくする Pull Requestのレビュアーがわかるような粒度のコミットにすること。小さいコミットのほうがわかりやすし、レビュアーの負担にもならない。
定期的にpushする pushはローカルと同じ名前のリモートリポジトリにpush する。他のメンバーがコードを見れるようになる。また、コードのバックアップにもなる。
Pull Requestを使う masterへのマージ依頼だけではなく、フィードバックがほしい時にPull Requestを出す。そうすれば間違いに早く気づく。マージではないPull Requestを送るときは、[WIP]をつけること。そうすれば間違ってマージするのを防げる。
参考URL
https://gist.github.com/Gab-km/3705015
http://www.atmarkit.co.jp/ait/articles/1401/21/news042.html